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IMPORTANT - PLEASE READ 

The purpose of this document is to describe certain characteristics of the operational environment 
and the safety and interoperability requirements for the systems and functions that support Air 
Traffic Services (ATS). This document also allocates the safety and interoperability requirements 
to the aircraft, communication network, ATS ground systems and the procedures used by the 
controller and the flight crew. This document will be used by the Boeing Company in its 
development of the FANS 1 upgrade for the 757 and 767. It will be used by the certification 
authorities to validate the safety and interoperability requirements for airworthiness approval of the 
airborne data link system and the applications and operational authorization to use the datalink 
applications. It will be used by ATS Service Providers and ATS applications developers to ensure 
safety and interoperability. It will be used by the airlines as substantiating data in order to obtain 
operational changes. This document will also be used to evaluate the modifications to any part of 
the system or procedures by providing guidance for the extent of validation required to 
substantiate continued safety and interoperability. 

The airworthiness approval of the FANS 1 data communication functions that support Air Traffic 
Services is based on the operational environment as defined in the 757/767 Air Traffic Services 
Systems Requirements and Objectives - Generation 2 (ATS SR&O), document number 
D926T0280. As such, the ATS SR&O and any revisions must be FAA approved through the 
Seattle Aircraft Certification Office prior to its use. 

At the time of the airworthiness approval of the 757/767 (Pegasus ‘00) FANS 1 FMC, the 
operational requirements described in revision A of the ATS SR&O were based on using the 
CPDLC message set to provide primary ATS communication in oceanic airspace as it is currently 
defined. The operational requirements for providing reduced separation minima and dynamic 
airborne route planning (DARP) based on FANS 1 communication capability were not determined. 
Therefore, there was no basis for qualifying the aircraft to any operational requirements. At such 
time when operational requirements have been determined, it may be necessary to incorporate 
into the ATS SR&O appropriate functionality or performance necessary to meet operational 
requirements and qualify the aircraft through the airworthiness approval process. Airspace 
planners must coordinate with the Boeing Company any functionality or performance that is not 
specifically defined in revision - of the ATS SR&O that is needed for operational capabilities not 
addressed in this document. The procedures delineated in Chapter 6 of this document and the 
procedures defined in the South Pacific Operations Manual may be used for this coordination. 

Certain safety and interoperability requirements could not be evaluated as part of the 
airworthiness approval of the 757/767 (Pegasus ‘00) FANS 1 FMC. Appendix D provides the 
requirements for validating safety and interoperability and indicates which of those requirements 
were satisfied as part of the commissioning of the ATS ground system or as part of the 
operational authorization to adequately ensure safety and interoperability of the FANS 1 data 
communication capabilities. 

To ensure the continued operational safety of FANS 1, it is important that airspace users and 
airspace managers report any problems to the Boeing Company. This would include any 
unintentional differences between aircraft types that may affect interoperability with the ATS 
ground systems or the communication network. ISPACG has established a problem reporting 
procedure contained in the South Pacific Operations Manual for this purpose^ 


Note that the ISPACG problem reporting procedure applies to operation in the South 
Pacific. Other operating regions may choose to define their own reporting procedures. 
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1.0 


PURPOSE AND SCOPE 

The purpose of this document is three-fold. First, it supports the development of an end-to-end 
Air Traffic Services (ATS) data communications system by documenting and allocating the 
requirements, ground rules, and constraints which are necessary for interoperability and which 
result from the safety assessment as delineated in Paragraph 9.0 of FAA notice 8110.50. The 
airborne environment considered will be the 757/767 (Pegasus ‘00) Flight Management Computer 
System (FMCS) Future Air Navigation System 1 (FANS 1) system, but the requirements 
documented herein are not intended to preclude FANS 1 implementations on other aircraft. The 
second purpose of this document is to support the Part 25 certification and Part 121 operational 
approval of the 757/767 (Pegasus ‘00) FMCS FANS 1 implementation. The third purpose of this 
document is to provide a means for substantiation of interoperability after changes to the end-to- 
end system. 

The Air Traffic Services Function transcends the scope of airplane systems as both ground and 
satellite systems participate in the function. Figure 1 provides an overview of the ATS 
participants. 


Figure 1 - FANS 1 ATS System 



Many references will be made concerning the "End-to-End ATS Function". This refers to the 
entire function and encompasses message processing by the airplane applications, datalink (air, 
satellite, and ground) and the ground applications. 


Rev: B 


D926T0280 


9 






















This document will support the development of an end-to-end ATS system by: 

• Defining interfaces between airborne, satellite, and ground 
environments; 

• Becoming a repository for interface decisions made during 
development; 

• Documenting necessary changes or clarifications to existing industry 
requirements (until they can be folded into the industry documents); 
and 

• Documenting limitations/exceptions of the 757/767 FANS 1 
implementations. 

This document will support Part 25 certification by: 

• Describing the overall requirements for the ATS function as they 
relate to the 757/767 FANS 1 implementations; 

• Supporting Safety/Failure Analysis by identifying those requirements 
which substantiate assumptions in the analysis; 

• Allocating the requirements to the airplane systems environment and 
non-airplane systems environment; and 

• Allocating the airplane systems requirements to the functional 
subsystems. 

The scope of this document shall be limited to the description of the Air Traffic Services Function 
as it relates to the implementation in the 757/767 (Pegasus ‘00) FMC FANS 1 Package. The 
functions of FANS 1 to be considered are: 

• ATS Facilities Notification Function (AFN) per ARINC 622-1; 

• Automatic Dependent Surveillance (ADS) per ARINC 745-2; 

• Two Way ATC Datalink (ATC DL) per RTCA DO-219; and 

• Datalink Function per ARINC 429 Supplement 13, ARINC 619, ARINC 
724B, ARINC 741, ARINC 716, ARINC 618, ARINC 622-1, and 
ARINC 620 

This document will not cover the requirements associated with the Airline Operational 
Communications Datalink (AOC DL). This document will also not cover the requirements or 
integration of the Global Navigation Satellite System (GNSS) as it does not participate directly in 
the ATS function. Ground-to-ground ATS communications are also beyond the scope of this 
document. 

Industry has recognized that the development of the ATS Function requires significant standards 
development. It is not the intent of this document to replace or supersede those standards. This 
document will make reference to existing standards wherever possible. However, it is recognized 
that some requirements are not yet documented. It is also recognized that the initial 
implementation of an ARINC 622 datalink system might require additions or changes to such 
standards. This document will contain any such changes or additions to the existing standards 
necessary for implementation. 

This document assumes previous knowledge of AFN, ATC DL and ADS message sets and 
functional requirements. 
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2.0 

DELETED 

3.0 

ORGANIZATION 


The organization of this document is described below. 

4.0 Industry Standards 

This section lists the industry standards which are related to the ATS 
functions and the ACARS datalink. 

5.0 ATS Functions 

This section provides a description of the ATS functions and the 
specific sections of the industry standards which apply to the FANS 1 
ATS functions. It also describes the additions, changes, deviations, or 
limitations made necessary by this development with respect to the 
industry standards. 

6.0 Operations 

This section describes how the ATS functions will be used 
operationally. 

7.0 Description of Environments 

This section describes the airplane, satellite, and ground 
environments. 

8.0 Allocation of Requirements to Environments 

This section will document the safety and interoperability requirements 
of the ATS functions. This section also allocates each requirement to 
an environment or to environments. 

9.0 Post-Certification Activity 

This section describes the methods for reporting problems found in 
service and for assuring continued interoperability of the end-to-end 
systems after some portion of the system has been modified. 

App A FANS 1 ATC DL Message Implementation 

This appendix contains specifics on the FANS 1 FMC implementation 
of the DO-219 message set. 

App B ADS Report Data 

This appendix contains specifics on the FANS 1 FMC implementation 
of the DO-219 message set. 

App C Traceability of Safety Assumptions to SR&O Requirements 
This appendix will provide the traceability between the safety 
requirements contained in this document and the FANS 1 Safety 
Assessments. This appendix also provides traceability between this 
document and FAA Notice N 8110.50. 

App D Validation Requirements for Assurance of Continued Interoperability 
This appendix provides guidance on how modifications to the end-to- 
end system must be validated in order to substantiate continued 
interoperability. This appendix also provides traceability between the 
section 8.0 requirements and the validation of those requirements. 

App E Differences Between ARINC 745-2, RTCA DO-212 and ADSP 
ATC/ADS Guidelines 

This appendix provides a comparison of the requirements for the ADS 
function as specified by ARINC 745-2, RTCA DO-212, and the 
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ADS/ATS Data Link Applications Guidance Material prepared by the 
ICAO ADS Panel. 

App F Differences Between the Desired FANS 1 Requirements and the 
Actual Implementation 

This appendix provides a list of the differences between the desired 
FANS 1 requirements and the actual implementation. 

App G ATC DL Error Processing 

This appendix provides a list of the ATC DL [errorinformation] error 
codes and the conditions under which each will be transmitted by the 
FMC. 


4.0 


INDUSTRY STANDARDS 


This section lists the industry standards which define the baseline for the ATS functions, including 
the ACARS datalink. 


a) ARINC 429, Mark 33 Digital Information Transfer System 

b) ARINC 429, Supplement 13, Williamsburg Protocol 

c) ARINC 618, Air-Ground Character Oriented Protocol Specification 

d) ARINC 619, ACARS Protocols for Avionics End Systems 

e) ARINC 620, Supplement 1, Datalink Ground System Standard and Interface Specification 

f) ARINC 622, Supplement 1 and 2, ATS Datalink Applications over ACARS Air-Ground 
Network 

g) ARINC 702, Flight Management Computer System 

h) ARINC 724B, Aircraft Communications Addressing and Reporting System 

i) ARINC 741, Aviation Satellite Communications System: Part 1 Supplement 6, Aircraft 
Installation Provisions and Part 2 Supplement 3, System Design and Equipment 

j) ARINC 716, Supplement 2, Aircraft VHF Communications Transceiver 

k) ARINC 745, Supplement 2, Automatic Dependent Surveillance 

l) RTCA DO-212, MOPS for ADS (developed by RTCA SC-170) 

m) RTCA DO-219, MOPS for ATC Comm Application (developed by RTCA SC-169) 

n) ADS/ATS Data Link Applications Guidance Material, ICAO ADS Panel 
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5.0 ATS FUNCTIONS 

The purpose of this section is to provide a description of the FANS 1 ATS functions. The 
interoperability, performance and safety requirements as allocated to the aircraft, another system 
or environment are stated in section 8.0. 

A table for each function specifies interoperability requirements by identifying portions of industry 
specifications that are applicable to the FANS 1 aircraft. When the industry specification states 
that a requirement is optional, then this section indicates whether or not the option is 
implemented. This section also identifies any deviations from or additions to the identified 
portions of the industry specifications. 

Figure 2 depicts the ATS functional relationships. 
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Figure 2 - ATS Functional Relationship 

There are four functions in Air Traffic Services: the AFN Function, the Datalink Function, the ADS 
Function and the ATC DL Function. The AFN Function provides the necessary information to the 
ground end system such that the ground ATC DL and ADS applications can establish 
communications links with the aircraft applications. The Datalink Function provides the data 
communications pathway for the AFN, ADS, and ATC DL Functions. The aircraft ADS Function 
provides surveillance information to the ground ADS function. The ATC DL Function provides a 
message set and allows data communications between the aircraft/flight crew and the ground 
systems/controller. 

The AFN, ADS, and ATC DL applications are end-system applications. This means that they are 
resident at each end of the end-to-end system. The Datalink Function is in each of the end 
systems and intermediate systems in the data communication pathway. The ACARS 
Convergence Function, which converts binary-oriented data to/from character-oriented data, is 
considered to be a sub-function of the Datalink Function and resides in the end systems. 


Rev: B 


D926T0280 


13 

















5.1 ATS FACILITIES NOTIFICATION FUNCTION 

The AFN function, described by ARINC 622-1 section 3.0, provides the transfer of information required to support the initiation of datalink 
connectivity between an airplane and an ATC Facility. The airborne AFN Function communicates with a peer AFN Function at an ATC Facility to 
notify the ground that the aircraft is ready for datalink services (and which datalink applications are supported by the aircraft) and to provide flight 
identifier, airplane address and application version numbers. The AFN is a character-oriented application, which does not require conversion by 
the ACARS convergence function as shown in Figure 2. 

Table 1 - AFN Clarifications/ Options/ Additions/ Deviations 


622-1 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

Description 

3.2.3.1 AFN 
Message Fleader 

Addition 

The AFN message header format will be modified from that shown in section 3.2.3.1. The header format, 
as shown in the downlink example below, will include an optional time stamp. 

/BO ctr_address.AFN/FMHflt_no,tail_no,,time_stamp ... CRCX. 

This time stamp allows the time that a message was formulated to be determined from ATS message 
recordings at the opposite end system. 

Clarification 

A valid time stamp which is included in an AFN uplink message header will be ignored. 

Clarification 

Only the overall response, not the individual application responses, found in AFN Acknowledgment uplinks 
will be used to determine whether the response is positive or negative. The flight crew is not made aware of 
the individual application responses. 

Clarification 

The AFN application is hosted in an ACARS peripheral, i.e., the FMC. Therefore, the AFN message format 
uses an MFI. 

Option 

The 24-bit ICAO Identifier, which is optional in AFN downlink messages, is not provided. 

A valid 24-bit ICAO identifier included in an AFN uplink will be ignored. 
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Description 


The ICAO code in an AFN Acknowledgment message must always contain the 4-character code of the ATC 
Facility sending the message. This is true even if the corresponding AFN Contact message contained the 
7-character network address of the ATC Facility. 

An active center address will not be stored. See deviation to 3.2.3.1.3 below. 

An active center will not be tracked and as such, AFN Contact Advisory uplinks will not be restricted to the 
active ATC Facility as defined in section 3.2.3.1.3. This means that an FN CON will be generated in 
response to any FN CAD message which is received unless an FNACK is already outstanding. The 
Active Flag in the downlink will be set to 1 if the Active Flag in the FN CAD message is set to 1 .This 
implementation was suggested at the first FANS 1 Interoperability Meeting and was adopted as a 
recommendation. The drawback of this implementation is that any ATC Facility can tell the aircraft to 
perform a transfer of address. 

The version number for the ARINC 745-2 ADS application is 01, not 02 as documented in Attachment. 

Attachment 3 ATS I Addition Following the syntax of Table 3-1, the time stamp parameter, will be defined as follows: 

Table 3-1 


Parameter 

Symbolic 

Length 

Format 

Note 

Time stamp 

time_stamp 

6 

HHMMSS 

1 



Deviation 

The message format for FANS 1 will allow alpha and/or numeric characters in ground addresses within AFN 
messages. This is because ground addresses today include the use of alpha characters and numeric. The 
standard is assumed to be in error. 

Attachment 3 ATS 
Table 3-2 

Addition 

The elements for the FMFI MTI are as follows: Flight number, Aircraft tail number, ICAO ID (optional), time 
stamp (optional). 


622-1 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

3.2.3.1.2 AFN 

Clarification 

Acknowledge 

Message 



Deviation 

3.2.3.1.3 AFN 

Deviation 

Contact Advisory 
Message 


Attachment 2 ACF 
IMI Table 2-1 

Deviation 
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622-1 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

Description 

Attachment 3 ATS 
Table 3-3 

Deviation 

The AFN application will use a 10 minute value for T, versus the 5 minute value specified in Attachment 3 
Table 3-3 of ARINC 622-1. Accordingly, T 2 and T 3 will be changed to 10 minutes and 15 minutes 
respectively. 


5.2 DATALINK FUNCTION 

The datalink function allows for the exchange of data among the various parts of the datalink applications, which are distributed among the aircraft 
and the ground host computers. (It allows the aircraft application and the associated peer ground application to communicate). The datalink 
function is generally described in ARINC 429 Supplement 13 (airborne), ARINC 619 (airborne), ARINC 724B (ACARS MU), ARINC 741 
(SATCOM), ARINC 716 (VHF), ARINC 618 (air-to-ground), ARINC 622-1 (end-to-end), and ARINC 620 (ground-to-ground). 

The datalink function and its relationship to system components is depicted in Figure 3 below: 



Figure 3 - Datalink Function 
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As seen in Figure 3, the datalink function is implemented in all environments. The majority of the datalink function is implemented in what is 
referred to as the ACARS Air-Ground Network. There are multiple air-ground networks, each operated by a service provider (SP). The primary 
networks are owned by ARINC and SITA. Internetworking between these service providers will be required for full operational benefits from these 
functions. 

A more detailed look at the ATS datalink message exchange process is contained in section 7. 

5.2.1 ACARS CONVERGENCE PROCESS 

The ACARS Convergence Process, defined by ARINC 622-1, is used to conform the ADS and ATC DL messages to the ACARS message format 
and to perform the CRC calculation and verification. 

Table 2 - ACP Clarifications/ Options/ Additions/ Deviations 


622-1 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

Description 

2.3 ACARS 

Convergence 

Message 

Formatting and 
Addressing 

Addition 

An uplink message up to the maximum ACARS message size limit will be accepted. The ACARS message 
size limit is 16 blocks, minus the ACARS sub-label field, the 622 message header and CRC, which is 
equivalent to 1709 octets of DO-219/DO-212 data. 

Clarification 

The ADS and ATC DL applications are hosted in an ACARS peripheral, i.e., the FMC. Therefore, the ADS 
and ATC DL message formats include an MFI. 

2.3.1 ADS 

Contracts 

Addition 

Only one address is allowed in the User Address Field of each ADS message. If there is more than one 
address in the User Address Field of an uplink ADS message, the message is considered invalid and is 
ignored. 


Rev: B 


D926T0280 


17 


















622-1 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

Description 

2.3.1 thru 

2.3.1.4.1, ACARS 
Convergence 
Function Message 
Format 


For FANS 1, the ACARS Convergence Process message format, defined in section 2.3.1, is modified to 
include the aircraft registration^](aircraft tail number) in each ADS and ATC DL downlink and uplink 
message, including the connection management related messages, as shown below. This is necessary to 
preclude the event where a datalink component could modify the addressing header and send a message 
to an airplane for which the message was not intended. 

• /MFI ATC_address.lMltail_numberATS_messageCRCX. 

The CRC calculation, defined in section 2.3.1.1, is modified to be performed over the IMI and the tail 
number (both with the eight bit of each character set to zero) and the bit-oriented application data. 


2 The ATS Data Link functions require an aircraft registration (tail number) which is provided by a DO-178B Level C or better system. The FMC 
does not have access to such an aircraft registration on the 757/767. The ACARS MU has access to a tail number through program pins, but the 
ACARS MU is a level D system. The following has been implemented in the 757/767 (Pegasus ‘00) FANS 1 system in order to ensure the integrity 
of the aircraft registration transmitted in ATS messages. 

Upon power-up, the FMC queries the ACARS MU for the aircraft registration via transmission of a documentary data request. If the MU responds 
with a documentary data response, the FMC uses the aircraft registration included in the documentary data response as follows: The first time a 
logon is attempted after installation of the FMC on a particular aircraft, the pilot is required to enter the aircraft registration on the ATC 
LOGON/STATUS page. The pilot entry is compared to the aircraft registration received from the ACARS MU. If the values match, then the entry is 
considered valid and is stored in the FMC’s memory. Each time the FMC is powered up thereafter, the aircraft registration received from the MU is 
compared to that stored in the FMC’s memory. If the two values match, then the aircraft registration is displayed on the ATC LOGON/STATUS 
page and no pilot entry is required. 

If the MU does not respond to the documentary data request, then the pilot is required to enter an aircraft registration, and any value that meets the 
format requirements is considered valid. 

Boeing has recommended that new ACARS software to support FANS 1 ATS Communications be able to support requests for documentary data, 
and be able to provide documentary data reports to the FMC. The format of the Documentary Data report should be as detailed in Table 5-2 of 
ARINC 619. (See 2.2.1.4 and 3.3.3 for further detail on how this data is used). 
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622-1 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

Description 

2.4.1 ADS 

Provisions 

Clarification 

The IMI used is “ADS”. 

Addition 

At flight completion the ADS application clears its tables and generates a (T_disconnect.req) primitive. 
(Disconnect reason 8). 

2.4.2 ATCComm 

Connection 

Establishment 

Clarification 

The IMIs are “CR1 ”, “CC1 ”, “ATI ” and “DR1 ”. 
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5.3 AUTOMATIC DEPENDENT SURVEILLANCE (ADS) 

ADS is a means of airborne surveillance in which an airplane function reports its current position, intent, and other pertinent information via the 
datalink function to an ATC Facility. ADS is defined by ARINC 745-2. This definition includes specification that the ADS reporting rate and the 
types of data to report are determined via uplink ADS contract requests from an ATC Facility and that a minimum of four ATC Facilities can be 
supported simultaneously. 


Table 3 - ADS Clarifications/ Options/ Additions/ Deviations 


745-2 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

Description 

ADS Downlink 
Message Buffering 

Addition 

The last 2 periodic reports, the last 2 on-demand reports and the last three event reports per connection are 
buffered. Messages generated beyond these capacities are lost. Note that under the remote condition in 
which there are 5 connections and at least one of the connections has a queued disconnect, upon a request 
from an ATS facility for a new connection, the queued disconnect, along with any other downlinks for that 
connection, will be erased to allocate resources for the new connection. 

3.2.2, ADS 

Request 

Processing and 

Supervisory 

Functions 

Deviation 

The ADS application does not support at least one connection with a periodic reporting interval of 4 
seconds. A minimum periodic reporting interval of 64 seconds on any or all connections is supported. If a 
periodic reporting interval which is less than 64 seconds is requested, a Noncompliance Notification is 
issued and that connection is assigned a reporting interval of 64-seconds instead. This 64 second 
minimum reporting interval is controlled by a Boeing controlled Operational Program Configuration (OPC)§] 

Option, not 
provided 

The (24-bit ICAO) Airframe Identification group is not provided. 


The OPC is a loadable file that is controlled by the Boeing Drawing System 
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745-2 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

Description 

3.2.2, ADS 

Request 

Processing and 
Supervisory 
Functions (cont’d) 

Option, 

provided 

5 ADS connections are provided. The airlines may choose to negotiate with ATS Service Providers to use 
one of these for company ADS reporting. 

3.2.2.1 ADS 

Periodic Contract 
Request 

Clarification 

If the aircraft is flying an offset path, the predicted TTG and altitude will be reported based on the original 
path. 

Clarification 

Predicted Aircraft Intent data are available in response to an ADS demand contract which requests Aircraft 
Intent and to the first periodic contract requesting the Aircraft Intent on a given connection if performance 
data are initialized. 

3.2.2.2 ADS Event 
Contract Request 

Clarification 

There has been some confusion as to the relationship of positive/negative climb rate versus the vertical rate 
thresholds. The following rules apply: 

• A positive vertical rate threshold can only be triggered during climbing flight; and 

• A negative vertical rate threshold can only be triggered during descending flight. 

3.2.3, ADS Report 
Assembly 

Functions 

Deviation 

The difference between the time stamp and position of the aircraft shall not exceed 1 second. The 
difference between the time stamp and the actual periodic or event trigger shall not exceed 2.5 seconds in a 
periodic or event report. The FMS formulates and attempts to send the appropriate NAK response within 2 
seconds. 
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745-2 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

Description 

3.2.5, Emergency 
Mode Operation 

Deviation 

The FMC complies with section 3.2.5 with the exception of the automatic change to a 64 second reporting 
interval. The FMC retains the current contract specified reporting interval when Emergency Mode 

Operation is initiated. If a reporting rate must be assigned for a default emergency mode contract (i.e., a 
periodic contract did not already exist on the connection), a 304 second reporting interval is used. 

This default emergency mode contract is not established when a new connection is established via an 
event request. 

3.3, Figure-of- 
Merit 

Addition 

The position determination accuracy portion of the Figure-of-Merit (FOM) does not take the accuracy of time 
into consideration, except when GPS is unavailable. The flight management function calculates the 
position determination accuracy as follows when GPS is being used as the time source: 

Calculated position uncertainty term (UT); 

The position determination accuracy is calculated as follows when the manually set flight deck clock is used 
as a backup time source: 

SQRT(UT 2 + (UTC error * Current Ground Speed) 2 ), 

3.4, ADS 

Messages 

Addition 

There is no minimum or maximum number of Intermediate Projected Intent groups specified in section 3.4. 

To provide a reasonable message size limitation, the FMC will send a maximum of 10 Intermediate 

Projected Intent groups in a given periodic report. 

Attachment 4-8, 

ADS Output 

Message 

Parameters 

Clarification 

The ETA field in the Predicted Route Group and the Projected Time field in the Intermediate Projected 

Intent Group will be reported as the estimated time-to-go (ETG). This is because the field definition does 
not encompass the 24-hour range necessary for an ETA. The use of ETA is assumed to be a misnomer in 
the standard. 


Deviation 

The valid range for distance is 0- 8191.750 nm; The default value for distance is 8191.875 nm. These 
modifications are assumed to be errors in the standard. 

Deviation 

The valid range for ETA and Projected Time is 0 -16382 seconds; The default value for ETA and Projected 
Time is 16383 seconds. These modifications are assumed to be errors in the standard. 
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745-2 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

Description 

Attachment 4-9, 

Clarification 

Zero is not a valid value for aircraft intent projected time. The aircraft intent proiected time must alwavs be 

ADS Intput 

Messaqe 

Parameters 


valid even when the aircraft intent aroup modulus is zero. 

Attachment 8-2, 

ADS Message Bit 
Map 

Representations 

Deviation 

In Figure 6, the MSB of the Vertical Rate Change Threshold field, and the Altitude Range Ceiling and Floor 
fields, should be marked as a sign bit. These bits will be set as such. This is assumed to be an error in the 
standard. 

Deviation 

In Figure 18a, the Intermediate Intent Group True Track field definition, the validity and sign bits are in the 
reverse order (from other validity and sign bits). These bits will be set in a manner which is consistent with 
the other on-request groups. This is assumed to be an error in the standard. 

Attachment 9, 7- 
Bit Format of 

Figure of Merit 

Deviation 

If GNSSUs are installed, the navigation Redundancy bit is set to one when at least one flight management 
computer’s position is valid. 

Otherwise, the navigation Redundancy bit is set to one when the position from more than one IRU is being 
used by the flight management computer. 
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5.4 ATC DATALINK (ATC DL) 

The ATC Datalink function enables the flight crew and ATS to interact using digital communication. The ATC DL requirements are defined by DO- 
219, the RTCA SC-169 MOPS for ATC Two-Way Data Link Communications. This functionality uses pre-defined ATS-to-pilot uplink and pilot-to- 
ATS downlink message element formats. Appendix A contains information about the FANS 1 FMC ATC DL message set implementation. 

Table 4 - ATC DL Clarifications/ Options/ Additions/ Deviations 


DO-219 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

Description 


Clarification 

A message which is larger than 1627 octets will not be generated. 


Clarification 

Default data are provided for downlink ATC DL reports where possible. The flight crew is allowed to enter 
over the provided defaults, unless the data in the report is from the corresponding uplink request (e.g., the 
[altitude] in the REACHING [altitude] downlink element is the same as the [altitude] in the corresponding 
uplink request, REPORT REACHING [altitude]), the data are not over-writeable. (See Appendix A for 
specifics on default data.) 


Clarification 

Metric altitude entries for downlink reports and requests are accepted, but all default vertical data and 
position report altitude data provided will be in feet or English flight levels. However, if a report request, 
such as REPORT LEAVING [altitude] is received, the corresponding report downlink will contain the same 
[altitude] data type as the uplink. 


Clarification 

As the definition of the [publishedidentifier] variable provides no means to limit the flight management 
function’s search for matching identifiers in its NDB, all NDB records are searched for a matching identifier. 
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DO-219 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

Description 


Clarification 

If a duplicate named waypoint (i.e., a ‘fixname’, ‘navaid’, or ‘publishedidentifier’ for which duplicates exist in 
the FMC’s Navigation Data Base) is received, the FMC will select the waypoint closest to the latitude and 
longitude of the flight plan fix after which the waypoint is loaded, the preceding [routeinformation] item, or 
current aircraft position, as appropriate for the element being loaded. Note that if the waypoint is defined as 
a [publishedidentifier] or [placebearingdistance] and the optional [latitudelongitude] is included with the 
[fixname], then the flight management computer will use that data to resolve the duplicate waypoint’s 
position. 

2.2.2, Connection 
Management 

Addition 

ATC DL connectivity requires initial contact establishment via AFN logon (to the initial ATC Facility). ATC 

DL connectivity is transferred as defined in DO-219 thereafter. The initial connection flow is basically as 
follows: 

AIRCRAFT GROUND 

AFN Contact -> 

< - AFN Acknowledgment 

< - ATC DL Connect Request 

ATC DL Connect Confirm -> 

Deviation 

The requirements related to the setting of TP4 timer values will not be met. Valid [tp4Table] data will be 
ignored. 

2.2.3.1, Message 
Attribute Tables 

Clarification 

A pending ATC DL message is defined to be an uplink or downlink message which has been transmitted 
and requires a closure response, as specified by the Response Attributes in section 2.2.3.1, but for which a 
response has not yet been received by or transmitted from the airborne ATC DL application. 

2.2.3.3, Message 
Structure and 
Content 

Deviation 

The uplink message element [track detail msg] (#178), defined in section 2.2.3.3, will be considered to be 
undefined. The uplink will be discarded and a downlink ERROR message (#62) with the ‘invalid data’ 
reason will be sent in the reply. 

Deviation 

An uplink message containing a [routeclearance] variable larger than 918 bytes will not be accepted. The 
uplink will be discarded and a downlink ERROR message (#62) with the ‘insufficient Msg Storage Capacity’ 
will be sent in reply. 
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DO-219 Section 


2.2.3.3, Message 
Structure and 
Content (cont’d) 


Clarification/ Description 
Option/ 

Addition/ 

Deviation 

Deviation An optional time stamp field is defined in the header of each ATC DL message as shown below. This 
definition syntax is consistent with that used in DO-219. 

ATCmessageheader ::= SEQUENCE 

{ 

Msgidentificationnumber, 

Msgreferencenumber OPTIONAL, 

Timestamp OPTIONAL 

} 

Timestamp ::= SEQUENCE 

{ 

Timehours, 

Timeminutes, 

Timeseconds 

} 

Timeseconds ::= INTEGER (0 .. 59) 

_ -Units = 1 Second, Range (0 .. 59) _ 

Correction The units for [frequencyvhf] and [frequencyuhf] are stated as .025. The units for these two variables should 
be .001. DO-219 is presumed to be in error. 

Addition The following ATC DL downlink message element (#80) will be defined in addition to the defined message 

set. The message structure and content will be as follows, per the abstract syntax defined in section 2.2.3: 

- DEVIATING [distanceoffset][direction] OF ROUTE Resp(N) 

dm80DistanceoffsetDirection [80] DM80DistanceoffsetDirection 
DM80DistanceoffsetDirection ::= DistanceoffsetDirection 

The alert attribute for this message is medium. The urgency attribute for this message 
is normal. 
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DO-219 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

Description 

2.2.3.3, Message 

Addition 

The downlink variable [positionreport] which is sent in the downlink message element POSITION REPORT 

Structure and 


(#48), will be defined as follows, per the abstract syntax defined in section 2.2.3. 

Content (Cont’d) 


Positionreport ::= SEQUENCE 
; 





1 

positioncurrent 

[0] Positioncurrent, 




timeatpositioncurrent 

[1] Timeatpositioncurrent, 




altitude 

[2] Altitude, 




fixnext 

[3] Fixnext 

OPTIONAL, 



timeetaatfixnext 

[4] Timeetaatfixnext 

OPTIONAL, 



fixnextplusone 

[5] Fixnextplusone 

OPTIONAL, 



timeetadestination 

[6] Timeetadestination 

OPTIONAL, 



remainingfuel 

[7] Remainingfuel 

OPTIONAL, 



temperature 

[8] Temperature 

OPTIONAL, 



winds 

[9] Winds 

OPTIONAL, 



turbulence 

[10] Turbulence 

OPTIONAL, 



icing 

[11] Icing 

OPTIONAL, 



speed 

[12] Speed 

OPTIONAL, 



speedground 

[13] Speedground 

OPTIONAL, 



verticalchange 

[14] Verticalchange 

OPTIONAL, 



trackangle 

[15] Trackangle 

OPTIONAL, 



trueheading 

[16] Trueheading 

OPTIONAL, 



distance 

[17] Distance 

OPTIONAL, 



supplementaryinformation 

[18] Supplimentaryinformation 

OPTIONAL, 



reportedwaypointposition 

[19] Reportedwaypointposition 

OPTIONAL, 



reportedwaypoi ntti me 

[20] Reportedwaypointtime 

OPTIONAL, 



reportedwaypointaltitude 

[21] Reportedwaypointaltitude 

OPTIONAL 



/ 

reportedwaypointposition ::= Position 




reportedwaypointtime ::= Time 





reportedwaypointaltitude ::= Altitude 
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DO-219 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

Description 

2.2.3.3, Message 
Structure and 
Content (Cont’d) 

Deviation 

The following downlink message elements, defined in section 2.2.3, will not be generated: 

• REQUEST [speed] TO [speed] (#19) 

• REQUEST VOICE CONTACT [frequency] (#21) 

• REQUEST WEATHER DEVIATION TO [position] VIA 
[route clearance] (#26) 

• WHEN CAN WE EXPECT [speed] TO [speed] (#50) 

• REQUEST VMC DESCENT (#69) 

Deviation 

FANS 1 ATC DL application will not consider aircraft type and equipment code data (airplane equipage) 
included in uplink message element 73, PREDEPARTURE CLEARANCE, to be loadable, printable, or 
displayable. 

Addition 

A message containing any IA5 string character not in the following set will be considered to be in error: 

(0..9), (A..Z), (,), (.), (), (/), (+), and (-). This applies to all message elements which contain IA5 string 
variables defined in section 2.2.3.3. The uplink message will be discarded and a downlink ERROR 
message (#62) with the ‘application error’ reason will be sent in reply. 
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DO-219 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

Description 

2.2.3.3, Message 
Structure and 
Content (Cont’d) 

Option 

When a standard POSITION REPORT message element (#48) is transmitted from the aircraft, the following 
variables will contain data, when such data are available. All other variables will contain no data. 

Positioncurrent 

timeatpositioncurrent 

altitude 

fixnext 

timeetaatfixnext 

fixnextplusone 

timeetadestination 

temperature 

winds 

speed 

reportedwaypointposition 

reportedwaypointtime 

reportedwaypointaltitude 

When a downlink message which contains the MAYDAY element (#56) is transmitted, an abbreviated 
position report containing the following data is included in the downlink. 

Positioncurrent 

timeatpositioncurrent 

altitude 

speed 
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DO-219 Section 

Clarification/ 

Option/ 

Addition/ 

Deviation 

Description 

2.2.4.2b Message 
Reference Number 

Addition 

A Message Reference Number shall be assigned for each ATC Comm message initiated for transmission 
with an [errorinformation] message element with the exception as indicated. The Message Reference 
Number shall be the Message Identification Number for the associated up-link message. If the message 
header of the associated up-link message does not contain enough bits to constitute a Message 

Identification Number, then no Message Reference Number shall be assigned for the corresponding ATC 
Comm message with the [errorinformation] element. 

2.2.5.4, Recall 
(para, b-e only) 

Option 

Message storage is done purely by time of arrival for uplinks, and time the message was selected for 
transmission for downlinks, and does not take into account the Recall types defined in section 2.2.5.4. 

Clarification 

The storage capability provided is as follows: 

75 non-pending uplinks and downlinks (5 of which can contain a [routeclearance] variable) and 10 pending 
uplinks (2 of which can contain a [routeclearance] variable) can be stored. When an uplink is received which 
would cause the pending uplink storage capacity to be exceeded, the uplink is discarded and a downlink 
ERROR message (#62) with the ‘insufficient storage capacity” reason is sent in reply. 

Clarification 

Non-pending uplinks and non-pending downlinks are automatically deleted when storage space is needed. 

The flight crew is also provided with the capability to delete any stored ATC DL message. 

2.2.6.3b Message 
Display 

Deviation 

If a message is received with an ERROR [errorinformation] or SERVICE UNAVAILABLE message element, 
the ATC DL function does not attempt to locate a pending downlink message, even if a Message Reference 
Number is included. The received message is displayed as an independent uplink message. (Refer to 
Appendix A.1, UPLINK MESSAGE ELEMENT TABLE). 
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DO-219 Section 


2.2.6.4, Pending 
Messages 


A.4.0 Downlink 
Messages 


Clarification/ 

Option/ 

Addition/ 

Deviation 

Deviation 


Deviation 


Clarification 

Addition 


Description 


Outstanding pilot requests are aborted when an END SERVICE message element is received, regardless of 
whether a transfer of data authority occurs. A subsequent uplink with a message reference number equal 
to the message identification number of an aborted downlink message will be rejected. A downlink ERROR 
message (#62) with the ‘unrecognized message reference number” reason will be sent in reply. 

Message identification numbers are allowed to be reused under the conditions listed in section 2.2.6.4c and 
when the downlink message has been deleted from message storage. The FANS 1 ATC DL application 
cycles through all message identification numbers before re-using any numbers. 

Downlink messages are not allowed to be generated when the storage for pending downlink messages is 
full (30 single block messages or 3300 octets). 

The table below defines the correlation between uplink report/confirmation requests (UL#) and the 
appropriate report downlink (DL#). When a report/confirmation request is received by the Airborne ATS 
Function, the Airborne ATS Function shall provide the flight crew the capability to formulate and transmit the 
corresponding report downlink as defined in the table below: 
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DO-219 Section 


A.4.0 Downlink 
Messages 


Clarification/ 

Option/ 

Addition/ 

Deviation 


Description 


Option 


Option 


When encoding a [placebearingdistance] or [publishedidentifier] for which duplicates exist in the NDB for 
the associated [fixname], the optional [latitudelongitude] will be included with the [placebearingdistance] or 
[publishedidentifier] in the downlink. _ 


Boeing aircraft will include DL#'s 29,30, and 80 in report downlink messages as defined in the table below. 


DL# 

Additional Information 

32,29,30 

DL#'s 29 or 30 sent with 32 if MCP alt more than 150 ft 
above/below baro-corrected alt 


DL# 80 sent with 40 if offset active 


DL# 80 sent with 42 if offset active 


DL# 80 sent with 44 if offset active 

48 

DL#'s 29 and 30 sent with 48 if MCP alt more than 150 ft 
above/below baro alt. 

DL# 80 sent with 48 if offset active 
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TIME STAMPING 




5.5 


The units and source of time used in the FANS 1 ATS system are as follows: 

Table 5 - Time Stamping 


Function 

Time Stamp Units 

Time Stamp Source 

ADS 

seconds from most recent hour 

The time source is GPS 
time referenced to UTC 
(reverts to Flight Deck 
Clock) 

ATC DL 

ETAs and RTAs use hours/minutes; Time 
stamp uses hours/minutes/ seconds 

The time source is GPS 
time referenced to UTC 
(reverts to Flight Deck 
Clock) 

AFN 

Hours/minutes/seconds 

The time source is GPS 
time referenced to UTC 
(reverts to Flight Deck 
Clock) 

ACARS Air- 
Ground Message 
Header 

Some use minutes/seconds from most 
recent hour as multi-block message #.f0 

Flight Deck Clock 

Service Provider 
Time Stamp 

Hours/minutes/seconds 

ARINC - WWVSE] 

SITA -0 


6.0 OPERATIONS 

This section describes how the ATS functions are intended to be used operationally^] and 
describes the basis for operational assumptions made during the safety assessment. 

Some operations use multiple functions, but it is important to understand the operation of the 
individual functions. This section provides a description of the operation of each function, 
including exceptional operations for probable airborne system failures. 

Loss of datalink can occur at any point in the datalink chain (as depicted in Figure 3). This 
section discusses probable failures together with the crew notification and corrective actions. 


Not recommended for FANS 1. It is recommended that true message sequence numbers 
be used instead of the time stamps to ensure detection of incomplete multi-block 
messages. 

WWVS is a NIST-approved stable signal standard accurate to +/- 5 msec. 

The SITA network will provide a time stamp within 2 seconds of UTC. 

Part 1 of the South Pacific Operations Manual defines detailed procedures for the use of 
ATC DL in the South Pacific. 
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The airborne failure discussion is specific to the 757/767 FANS 1 implementation. Failures can 
be caused by equipment failures or message transmission failures, and can occur during 
operation or prior to dispatch. The phase of operation and the type of failure determine the 
annunciation philosophy used. 

6.1 GENERAL OPERATIONS 

The ATS functions, being discussed herein, are resident in the FMCS. Before any discussion of 
failure modes, it is important to understand some of the architecture of the FMCS installation in 
the 757 and 767. 

While there are two FMCs installed in the airplane, only one of them provides guidance and 
control at any given time, as determined by the selected autopilot (Left or Center A/P in CMD will 
make the left FMC master, Right A/P in CMD will make the R-FMC the master) or the Navigation 
source select switches. Failure of either FMC is annunciated by an EICAS advisory message. 
The selected FMC is known as the Master FMC and the other is referred to as the Spare. If the 
Master FMC fails, the crew then selects the offside FMC by changing engaged autopilots, or via 
the navigation source selector and it becomes the Master. 

For the 757/767 (Pegasus ‘00) FMC, the datalink master follows the normal FMC master 
switching logic as described above. This assumes that the airplane has the ACARS wired into 
both FMCs. 

Failure of the Slave FMC has no impact on the datalink connections. If the Master FMC fails, the 
spare FMC which has been kept updated concerning the ATS functions and status, takes over 
the ATS functions when the crew selects the other FMC, as described above. Messages in the 
process of being sent to the MU at the time of Master switch are reinitialized. Messages in the 
process of being received from the MU are not acknowledged and the MU re-sends the message. 

ACARS equipment failures are annunciated on the EICAS system as an advisory message. If an 
ACARS MU should fail, all messages in the process of being transmitted to the FMC at the time of 
failure are lost.E] If the FMC was transmitting a downlink at the time of an MU failure, the FMC 
detects the failure via the lack of positive status from the MU. 

There is no direct annunciation of VHF failures. If the MU detects lack of activity on the VHF (no 
ACKs) then it will switch to SATCOM. 

The SATCOM system has EICAS messages which alert the crew to an equipment failure 

The pre-flight state and condition of the airborne datalink and application system are ascertained 
by the crew by review of the EICAS Alert and Status messages prior to dispatch. 

Failures in the non-airplane portion of datalink are detected by the MU through protocol timers. 
This means that if the Service Provider or ATC Facility does not respond in a certain amount of 
time or in the proper manner, the ACARS MU or FMC, respectively, detects the lack of the 
specified response and annunciates this fact. 

The MU also provides status of the SATCOM and VHF sub-networks to the FMC and EICAS. 
The FMC and EICAS use these inputs to provide ‘datalink’ status to the crew. 


This assumes a single MU installation. 
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6.2 PREFLIGHT AND DISPATCH 

The status of the airborne equipment associated with ATS functions is available. The Airplane 
Flight Manual (AFM) and Mandatory Minimum Equipment List (MMEL) are used with the crew 
alerting displays to ascertain dispatchability of the aircraft. 

6.2.1 INITIAL CONNECTION 

Under normal operations, the flight crew performs the pre-flight logon using the 4-character ICAO 
identifier of the initial ATC Facility with whom they wish to communicate. This datum is available 
from the onboard Jeppesen charts or provided by the airline dispatch office. The logon provides 
aircraft and avionic end system addressing information, and ATS application version numbers, 
which the ground applications need to initiate communication. The ATC Facility ensures that the 
ground application versions are compatible with the airborne versions. 

If the FMC indicates that the logon is successful (i.e., the ICAO code matches and the AFN 
acknowledgment reason is set equal to 0), the flight crew assumes that the ATC Facility has the 
ADS and/or ATC DL functions active unless a current NOTAM notifies them of the unavailability of 
one of those functions. The ATC Facility then initiates ATC DL and/or ADS communication with 
the aircraft. The logon must be successful in order to establish the ATC DL communication. From 
the FMC’s point of view, the activation of the ADS function is not directly dependent on previous 
activation of the AFN function to establish the communications link. However, operationally, AFN 
notification to the initial ATC Facility may be required to provide the appropriate addressing and 
status information. 

The ATC Facilities forward the logon information along the filed flight route (from sector to sector, 
facility to facility, or FIR to FIR) using ground network communications. The ATC Facilities may 
use the AFN function to transfer logon information if ground to ground communication is not 
available.!] (See section 6.7.2 for more on Switching ATS Facilities.) 

No response within 10 minutes or a response indicating other than a successful logon (AFN 
acknowledgment reason is not equal to 0), is considered to be a negative response. The crew is 
notified of a negative response via CDU scratch pad/EICAS messages and assumes that ATS 
applications are not active at the selected facility. If the ATC Facility attempted to initiate ATC DL 
communication at this time, the aircraft would not respond. 

The crew may initiate AFN logon activity at any time, e.g. if datalink connectivity is lost, to attempt 
to establish datalink connectivity. 

6.3 SURVEILLANCE 

Surveillance of the aircraft in the non-radar environment uses both the ADS Function and the ATC 
DL Function. The primary surveillance vehicle is ADS, but ATC DL can be used in tactical 
situations when needed. 

6.3.1 SURVEILLANCE USING ADS 

The ATC Facility has the information necessary to establish ADS reporting with airplanes in or 
near their FIR, via the logon process discussed in 6.2.1 or through other means as discussed in 
6.7.2. 


MITRE (for the FAA) and the CAA Australia stated that the AFN process will not affect 
current procedures governing exchanges of logon information, including the Flight Plan. 
Ground-Ground Communication interfaces are defined in ADSP Guidance Material. 
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The ATC Facility has the capability to request periodic reports, event driven reports and 
immediate on-demand reports. 

The flight crew is not required to interact with ADS to provide reporting, but the crew does have 
the ability to enable/disable ADS reporting via the CDU. When ADS is enabled (default state upon 
power-up), ADS responds automatically to requests from up to five ATC Facilities.F’lThe airlines 
may choose to negotiate with ATS Service Providers to use one of these for company ADS 
reporting. The flight crew has access to ADS connection status through the CDU. Active status is 
displayed to the crew while at least one ADS connection is established. 

6.3.1.1 ADS PERIODIC REPORTS 

The ATC Facility initiates a periodic report using an uplink periodic contract request which defines 
the contract and the reporting frequency. The periodic contract remains in effect until the contract 
is canceled by the ATC Facility or flight completion is achieved. 

The ATC Facility may request that optional data groups be added to the basic ADS report (see 
Appendix B) and specifies the frequency at which those groups should be added to the basic 
report. The ATC Facility also has the capability to add new optional groups, change optional 
group reporting frequency, and stop reporting of individual optional groups. 

6.3.1.2 ADS WAYPOINT POSITION REPORTS 

One event driven report causes an ADS position report to be generated when the airplane 
sequences a waypoint. This report refers to the ADS Waypoint Change report as defined in 
ARINC 745 and is similar to, but distinct from, the position report defined in ARINC 702. The 
Waypoint Change report by definition includes the basic ADS report and the Predicted Route 
group. Such a report is sent for each waypoint sequence (individual waypoints are not selected by 
the ATC Facility) and the reporting does not affect the frequency of the periodic reports. It should 
be noted that the ADS waypoint position report downlinks do not include waypoint identifiers (i.e., 
all positions are in latitude/longitude format). 

The flight management computer does not distinguish between compulsory waypoints and any 
other waypoint type. This means that the ADS position reports will be generated when any 
waypoint is sequenced. Any pilot modifications to the filed flight plan which add or delete 
waypoints will affect the position reports. The flight crew procedurally assures that they do not 
modify or delete compulsory waypoints. ATS must recognize that position reports may be 
received for waypoints which do not exist on the filed flight plan. It should also be noted that the 
ADS position report downlinks for the 757/767 (Pegasus ‘00) FANS 1 implementation contain the 
current airplane information at the time of the waypoint sequence. 

6.3.2 SURVEILLANCE USING ATC DL 

The ATC Facility has the information necessary to establish ATC DL communication, but because 
the ATC DL application only supports one ATC Facility at a time (except for transfer of service 
purposes), this communication is limited to the aircraft actually in the ATC Facility’s control. 

The ATC DL Message set (see Appendix A) contains many messages which help the ATC Facility 
establish tighter surveillance over aircraft. These messages are in the following classes: 


The industry definitions and the 757/767 (Pegasus ‘00) FANS 1 implementation of ADS 
do not allow the airborne system to know which of the five contracts is from the controlling 
center. Established procedures, as defined in Section 7 of the South Pacific Operations 
Manual ensure that the controlling ATC center gets one of the connections. 
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• Uplink Contact/Monitor/Surveillance Requests; 

• Uplink Report/Confirmation Requests; and 

• Downlink Reports, including position reports. 

It should be noted that an ATC DL position report contains similar information to the ARINC 702, 
ADS, and ICAO position reports; but is distinct and is defined in DO-219. 

6.3.3 EXCEPTIONAL OPERATIONS 

Invalid uplinks are recognized by the airborne application. If the error is found during the ARINC 
622 processing (e.g., a CRC failure), no response is sent and the ground views this as an 
outstanding message. If the error is found during the ADS decoding, the appropriate ADS 
response is sent back via the network. 

ADS reporting is controlled by the ATC Facilities without crew interaction. Therefore failure 
annunciation to the crew of specific failures of ADS connections is not possible. The loss of the 
datalink function is the only failure annunciation required for this function and is discussed in 
section 6.2.1. 

After 16 consecutive minutes of NOCOMM, VOICE only, or FAIL, the FMC terminates all ADS 
contracts and connections. The ADS status is changed to inform the crew that there are no ADS 
connections currently established. The FMC considers NOCOMM to be true when the MU 
asserts that all available datalink media are NOCOMM (see section 7.1). 

If the loss of the datalink function or the ADS function is due to an aircraft failure, the crew initiates 
voice contact via the established procedures using direct or third party HF Radio, VHF Radio or 
SATCOM voiceHl Verbal position reports are used to establish contact. If the datalink loss is 
due to a localized ground problem, the aircraft systems may not be able to detect this, and the 
crew may not be informed that the ADS connection is effectively lost. 

The ground ADS application has a timer installed which is started when an uplink ADS message 
is sent and waits for the appropriate ADS response. If the timer expires, the ATC Facility can re¬ 
generate the uplink. 

The loss of an ADS periodic or event report can be recognized by various means (e.g., by no 
periodic report for 1 and 1/2 times the report period). Once alerted by automation or ATS 
procedures to a possible loss of ADS connectivity, the ATC Facility initiates a one-time demand 
request. If the demand request is not responded to by the aircraft, the controller should revert to 
established procedures, such as voice communications with the aircraft. 

If the situation arises where there are no contracts on a given connection for 16 consecutive 
minutes, the ADS function will automatically terminate the connection by sending a Disconnect 
Request. This will not affect the operation of any other ADS connection. Note that this Contract 
Inactivity Timer is part of the ADS application and is independent of the 16 minute NO COMM 
timer. 


SATCOM voice is not a requirement for FANS 1 implementation. 
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6.4 GENERAL PILOT CONTROLLER COMMUNICATIONS 

After the ATC Facility responds to the aircraft logon and when the ATC Facility is ready, the ATC 
Facility sends an ATC DL uplink connection request (contains message element #163 [ICAO 
facility designation]) to the aircraft to initiate ATC DL connectivity. When the airborne ATC DL 
application receives the message, it responds automatically with a downlink connection confirm 
(contains message element #73 [version number]). After this exchange, the flight crew can 
exchange general ATC DL messages with the ATC Facility.EH] The airborne ATC DL application 
will only accept messages for the flight crew (some connection establishment and system 
management type messages can be exchanged) from a single ATC Facility. 

There are procedural constraints on ATC DL communication as it is possible for communication 
to be established with an ATC Facility other than the controlling facility. The flight crew does not 
select with whom they communicate, but the code of the ATC Facility to which they are 
communicating should be displayed. These procedures will constrain ATC Facilities' ability to 
establish connections with aircraft that are not being provided separation service, limit the type of 
communication (i.e. no active clearances) with other than the active center, or formalize 
communication termination procedures (i.e., pilot should turn ATC DL off). 

6.4.1 EXCEPTIONAL OPERATIONS 

There are error conditions defined in RTCA DO-219 which cause termination of the active, and 
thereby the inactive if it exists, ATC DL connections. 

A change of aircraft addressing information in the ATS application system causes a loss of ATC 
DL communication. On the 757 and 767, the specific conditions which would result in loss of ATC 
DL communication are pilot entry of a different flight number, pilot entry of a different aircraft 
registration number (tail number), or the automatic clearing of flight number at flight completion. 

After 16 consecutive minutes of NOCOMM, VOICE only, or FAIL, ATC DL connection(s) are 
terminated by the airborne application. The FMC considers NOCOMM to be true when the MU 
asserts that all available datalink media are NOCOMM (see section 7.1). The flight crew will be 
notified of the loss of ATC DL connectivity via CDU scratch pad/EICAS messages. In the case 
that an ATC DL failure is annunciated to the pilot, the flight crew may reinitiate connectivity by 
repeating the logon scenario described in section 6.2.1. When an ATC Facility receives a logon 
when an ATC DL connection appears to already exist with the aircraft, the ATC Facility may 
conclude that a failure recovery has occurred in the aircraft ATC DL application. Any pending 
uplink messages which exist between the ATC Facility and that aircraft at the time of the logon 
receipt would be considered to have failed. The ATC Facility would then respond to the logon in 
the normal fashion. 

Similarly, in the case of a ground ATC DL application restart after unexpected shutdown, the 
aircraft accepts a connection request from an ATC Facility to which it appears to already be 
connected. The FMC, however, should handle the transaction transparent to the flight crew; there 
should be no flight deck effect.PI 

In the case of a failure which does not cause loss of the ATC DL function, but which warrants 
termination of the function, the pilot may select ATC DL off, thus terminating all connections. 


Comprehensive connection establishment procedures and criteria are contained in DO- 
219 and Part 1 of the South Pacific Operations Manual. 

Part 1 of the South Pacific Operations Manual specifies procedures for handling a failure 
of the ATC DL connection. 
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If the aircraft receives an ATC DL connection request from a new ATC Facility while an ATC DL 
connection is already established, the airborne ATC DL application will send a Disconnect 
Request in response, except for the case of a valid communication transfer. The Disconnect 
Request will contain the identifier of the active ATC Facility (message element #64). (See section 
6.7.2.2 for ATC DL communication transfer process). 

Procedures accommodate non-delivery of ATC DL messages which specifically require a closure 
response (e.g., WILCO). Impact for non-delivery of uplink and downlink messages (by individual 
elements) which do not specifically require a closure response is shown in the table below. The 
referenced section contains additional exceptional operations description for the message 
element(s). 


Uplink 

Message 

Elements 

Description 

Impact 

Ref. 

Section 

0-5 


Acceptable. Uplink expected by crew. 

6.6.2 

131-147, 181- 
182 

Requests for 
Reports 

Acceptable. Corresponding downlink report 
expected by ATS. 

6.3.3 

148, 152 

When Can You... 

Acceptable. Corresponding response 
expected by ATS. 

6.5.3 

159, 162 


Acceptable. Minor effect on operations. 

6.5.3, 

6.6.2, 6.7.4 

160, 161, 163 

[BiS rffijprSfiF- ' 

Acceptable. Minor effect on operations. 

6.7.4 

165-167 

Additional 

Messages 

N/A. These message elements will only be 
sent with other message elements. 

- 


Downlink 

Message 

Elements 

Example 

Impact 

Ref. 

Section 

0-5 

Responses 

Acceptable. Downlink expected by ATS. 

6.5.3 

28-48, 72, 76- 
79 

Reports 

Acceptable. Downlink expected by ATS 

6.3.3 

55-61 

Emergency 

Messages 

Acceptable. Uplink response expected by 
crew. 

6.9 

62-64 

System 

Management 

Acceptable. Minor effect on operations. 

6.4.1, 

6.5.3, 6.7.4 

73 

Connection 

Management 

Acceptable. Minor effect on operations. 

6.4.1 

65-66, 74-75 

Additional 

Messages 

N/A. These message elements will only be 
sent with other message elements. 

- 

67 

Free Text with 
Normal Urgency 

Acceptable. If delivery needs to be 
assured, use Free Text with distress 
urgency (#68). 

6.5.3, 6.6.2 
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6.4.2 


MESSAGE STORAGE 

ATC DL messages are stored in the order received or created. The pilot has the ability to recall 
the messages for review and to print them on the onboard printer. The 757/767 (Pegasus ‘00) 
FMC can store 75 non-pending uplinks and downlinks (5 of which can contain a [route clearance] 
variable), 10 pending uplinks, (2 of which can contain a [route clearance] variable) and 30 blocks 
(3300 octets) of pending downlinks. The FMC will automatically delete the oldest uplink or 
downlink when storage space is needed for new messages. (New downlinks cannot be generated 
when the storage for pending downlinks is full. The flight crew can delete stored messages. The 
ATC log clears 10 minutes after flight completion. 

The ATC DL messages both ground initiated and crew initiated, are recorded by the network 
service provider (see section 8.2.3.2.2). It is also the intention of several ATC Facilities to record 
ATC DL messages. 

6.5 TACTICAL INTERVENTION INITIATED BY ATS 

ATS uses the ATC DL message set to initiate/negotiate tactical changes via uplinks to the aircraft. 
When an uplink is received and is available for review, the pilot is alerted. The pilot should display 
the message and act accordingly. Some messages contain flight plan data which can be loaded 
into the FMC, reviewed, and executed. Some messages contain flight plan data which can be 
loaded into the flight management function, reviewed, and executed. See Appendix A for 
loadable uplink message elements. 

6.5.1 FLIGHT PLAN CHANGE LIMITATIONS 

Portions of the predeparture clearance and route clearance uplink messages are not reviewable 
except on the flight deck printer (see section 7.1.7). 

6.5.2 NEGOTIATIONS 

The airborne ATC DL application provides the flight crew with response prompts for uplink 
messages, as appropriate, for the received uplink. The potential response prompts are: 

• Accept 

• Standby 

• Reject 

If the pilot selects reject, the pilot may then add rationale (reject due to performance or weather) 
and free text to the message for negotiation purposes. The crew decision is sent in a downlink 
message to the ground ATC DL application using the appropriate response message (e.g., 
WILCO or UNABLE). ATS and the pilot can then exchange messages until suitable procedures 
have been established. 

6.5.3 EXCEPTIONAL OPERATIONS 

The abnormal operations involving loss of datalink or the ATC DL application are handled the 
same as described in section 6.4.1. Refer to Figure 5 for an illustration of detection and handling 
of uplink datalink errors. 

For uplink messages which require a crew response (as defined by DO-219), the ground ATC DL 
application has a timer installed which waits for the appropriate crew response. If the timer 
expires, the ATC Facility can initiate another message or contact the aircraft via voice. For uplink 
messages which do not require a crew response, the table in section 6.4.1 shows the impact of 
message non-delivery. 
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Invalid uplinks are recognized by the airborne application. If the error is found during the ARINC 
622 processing (e.g., a CRC failure), no response is sent and the ground views this as an 
outstanding message. If the error is found during the ATC DL decoding, an ATC DL error 
response is sent back via the network. Again, ATS can choose to uplink another message or 
initiate voice contact. 

6.6 TACTICAL MODIFICATION REQUESTED BY CREW 

The flight crew can request route modifications, route replacements, lateral path modifications 
(offset, Direct To), and vertical path modifications. 

A route request may either be a route modified^! by the crew, or a route which has been sent to 
the airplane from the Airline Data SystemThe active route, modified active route, or inactive 
route may be used to hold a requested route. The entire route (if en route, only the current 
waypoint and on) including arrival, and departure procedures (if applicable)^ will be sent. The 
crew can also separately request departure/arrival or transition procedures, offsets, vertical 
clearances, or ‘direct to’ clearances. 

6.6.1 NEGOTIATIONS 

If an ATC Facility receives a path modification request and the request is acceptable, the ATC 
Facility uplinks the requested route as an appropriate clearance. The crew can then load and 
execute the path modification uplink, if such functionality is provided for the particular airplane 
model. If the request is not acceptable, the ATC Facility sends a rejection message and/or an 
alternative path modification. 

If the ATC Facility does not support the particular pilot request, the ATC Facility responds 
accordingly with the uplink 'SERVICE UNAVAILABLE'. 

ATS may send 'REQUEST DEFERRED' or 'STANDBY' as a temporary response to a request. 
The flight crew will expect a further response for the request. 

6.6.2 EXCEPTIONAL OPERATIONS 

Refer to Figure 6 for an illustration of downlink error detection. 


The following terms defined here for information: The ’active route’ is the route to which 
the flight management function is guiding the aircraft; a ’modified active route' exists if the 
flight crew has made changes to the active route which have not been executed, the 
modifications are not being used for control; the 'inactive route' is a standby route which 
can be empty or may contain a route which can be activated at any time; a fixed location 
'waypoint' is a named fix (navaid, airport, other geographic location) in the Navigation 
Database, a latitude/longitude, or a bearing and distance from a named fix. A route is 
flown by guiding to reach the active waypoint, then 'sequencing a waypoint' by satisfying 
the conditions for reaching the waypoint, and then guiding to reach the next waypoint in 
the route. 

The route can be sent by airline operations directly to the ATC Facility via AIDC, for 
example, for review and uplink to the aircraft. 

Departure airport and runway are always sent if entered. The arrival airport will be sent if 
entered. Airways and planned holds will be sent if they exist. 
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Invalid downlinks are recognized by the ATC Facility. If the error is found during the ARINC 622 
processing (e.g., a CRC failure), no response is sent and the flight crew views this as an 
outstanding message. If the error is found during the ATC DL decoding, an ATC DL error 
response is sent back via the network and the flight crew is so notified. The flight crew can 
choose to downlink another message or initiate voice contact. 

The ATC DL application starts a network acknowledgment time[2Z| when the pilot initiates a 
downlink message. While the network acknowledgment timer is running, the pilot cannot 
retransmit the corresponding message. Once the timer expires, the corresponding message 
remains open, if a response is expected. However, the pilot can still choose to resend or initiate 
voice contact. 

When the network Acknowledgment is received for the downlink message, the message status 
transitions from SENDING to SENT or OPEN. The status is OPEN if a response is expected (by 
the FMC as defined in DO-219) from the ATC Facility. The OPEN status will remain until a 
response is received for that message from the ATC Facility. The table in section 6.4.1 shows the 
impact of message non-delivery for downlink messages which do not require an ATS response. 

6.7 SWITCHING ATS FACILITIES OR VHF VOICE TO DATALINK 

6.7.1 VHF VOICE TO DATALINK 

There are no messages defined which relate to specific types of clearances such as tower, en 
route, oceanic, etc. Therefore, such clearances are procedurally handled using other messages. 
For example, an ATC DL route clearance uplink with a "cross position at time" message fulfills the 
intent of a pre-departure clearance used for oceanic/remote applications. The crew establishes 
their initial link with the departure ATS authority and receives their pre-departure clearance 
including pertinent oceanic/remote area elements. The aircraft uses applicable VHF 
communications until it exits the area where VHF voice is used and enters the area where datalink 
usage is necessary (e.g., an oceanic FIR). The departure ATC Facility would have transferred 
communications in order to establish datalink communications. 

6.7.2 ATC FACILITY TO FACILITY, OR FIR TO FIR 

The FIRs, with their associated ATC Facilities, coordinate (between themselves) for transfer of 
control via ground networks. They accomplish transfer of communication via uplink to the 
airborne end system when both facilities have established datalink communication. Aircraft 
addresses can be forwarded from ATC Facility to ATC Facility if ground connectivity is available. 
If ground connectivity is not available, an ATC Facility may request the aircraft to forward its 
addresses to another ATC Facility through the AFN Function. 

The controlling ATC Facility uses the AFN application to automatically (i.e., without pilot 
interaction) transfer logon information by sending an uplink AFN Contact Advisory message. The 
Contact Advisory contains the next ATC Facility’s network address. The AFN application 
automatically responds with a downlink AFN Response message indicating intent to perform the 
logon and then automatically goes through the same process as an initial logon. The AFN 
application sends a downlink AFN Complete message to the requesting ATC Facility with the 
result of the logon to the next facility. 


The Network Acknowledgment timer in the 757/767 (Pegasus ‘00) FMC is set to 5 
minutes. This value is contained in the FMC’s Operational Program Configuration (OPC) 
file. 


Rev: B 


D926T0280 


42 



6.7.2.1 




ADS SWITCHING 

The ground ATC Facilities wishing ADS data coordinate amongst themselves to assure that no 
more than five ATC Facilities are attempting to request ADS data from the aircraft and that the 
controlling facility is one of the five which is receiving ADS data. This requires that the ATC 
Facilities terminate their contracts when data are no longer needed to assure that the next ground 
facility can initiate contracts. Ground to ground communications can be used to forward ADS 
reports from one ATC Facility to the next.Pl 

6.7.2.2 ATC DL SWITCHING 

ATC DL is transferred by designating a NEXT DATA AUTHORITY who is allowed to establish an 
ATC DL connection with the aircraft. This connection does not allow pilot-controller dialogue until 
the switch is complete. Once this connection is established, the ATC Facility allows termination 
of the active ATC DL connection by sending up one of the following: 

• Message 5, as shown below in Figure 4, or 

• Message 5 without the instruction to pilot regarding transfer (see Section 6.8). 



Figure 4 - ATC DL Transfer 


Part 7 of the South Pacific Operations Manual specifies procedures for establishing and 
prioritizing ADS connections. 
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Label 

Message 

1 

Next Data Authority 

2 

DELETED 

3 

Connection Request (with user data) 

4 

Connection Confirm (with user data) 

50 

Contact or Monitor instruction0+ End Service 

6 

WILCO 

7 

Disconnect Request 

8 

Normal message traffic 


The scenario in Figure 4 was originally developed by the ICAO ADS Panel. Message 7 has been 
added to show the Disconnect Request. If the aircraft is transferring from a region without data 
link capability to a region with data link capability, messages 1,5, 6, and 7 are not transmitted. If 
the aircraft is transferring from a region with data link capability to a region without data link 
capability, messages 3, 4, and 8 are not transmitted. Message triggering mechanisms for 
associated messages are designed to accommodate these scenarios. Note that the ground-to- 
ground messages do not necessarily imply data communications. 

6.7.3 DATALINK TO VHF VOICE 

There is no automatic sequencing of ATS functions when the aircraft transits from datalink 
communication to voice communication (e.g., datalink equipped ATC Facility to non-datalink 
equipped ATC Facility). The crew procedurally transfers to voice contact and uses current 
applicable procedures. (See section 6.8 for terminating datalink communication.) 

6.7.4 EXCEPTIONAL OPERATIONS 

For crew annunciated datalink or application failures, the crew can re-initiate the AFN logon 
function. Other failures are handled procedurally. 

Any abnormal condition which causes termination of the active ATC DL connection causes 
termination of the connection awaiting transfer of communication, if it exists. 

If the result of either the AFN Response or the AFN Complete (discussed in section 6.7.2) is 
negative, the ATC Facility can either re-attempt the Contact Advisory or contact the aircraft and 
instruct the crew to perform a manual logon. 

In the event that the controlling ATC Facility cannot establish an ADS connection (due to the 
aircraft already having five ATC Facility connections in place), but the facility has an ATC DL 
connection, a free text message can be sent to the flight crew to notify them of the problem. The 
flight crew can then turn off ADS and re-enable it via the CDU. This will allow the controlling ATC 
Facility to establish an ADS contract. 


Some FIRs send Contact or Monitor instructions and the END SERVICE element as 
separate messages. Refer to Part 1 of the South Pacific Operations Manual. 

Note that technically any message element which requires a WILCO can legally be 
combined with the END SERVICE message element. 
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In the event that the ATC Facility which will be accepting control, cannot establish an ADS 
connection (due to the aircraft already having five ATC Facility connections in place), voice 
contact can be used for the same purpose. 

6.8 TERMINATION 

If the End Service (message 5 in Figure 4, section 6.7.2) is sent up without the Contact or Monitor 
instruction, the ATC DL application sends the Disconnect Request immediately and without pilot 
notification. 

The controlling ATC Facility may, as an alternative, inform the pilot, through voice or data 
communication, to terminate the connection. 

There is an uplink disconnect request defined in ARINC 622-2. This uplink disconnect request 
was designed to be used by an ATC Facility to terminate service in the event of an orderly failure 
or service termination whereby a transfer is not intended even though a NEXT DATA 
AUTHORITY message was sent. 

An ATC Facility may send an ATC DL uplink message with END SERVICE and an error message 
to gain the same effect as the uplink disconnect request. This uplink is an invalid uplink, and thus 
will cause the aircraft ATC DL application to terminate all connections (and thereby not transfer 
communications) as desired.FH 

The aircraft terminates the active, and thereby the inactive if it exists, ATC DL connections under 
the following abnormal circumstances: 

• Loss of data link communication for 16 minutes (section 6.4.1); 

• Pilot initiated termination, including a change of flight number or aircraft registration 
(tail number) (section 6.4.1); 

• Receipt of an uplink disconnect request, and 

• Error conditions defined in RTCA DO-219. 

ADS and ATC DL connections are terminated automatically at flight completion. 

6.9 EMERGENCY OPERATIONS 

The aircraft or ATS can initiate emergency operations^ There are no specific procedures 
associated with datalink communications for the initiation or termination of those operations by 
ATS. ATS would use the general/tactical ATC DL messages to handle the emergency. 

Using ATC DL, the flight crew can send a MAYDAY message and also inform ATS of the aircraft's 
immediate intent. The aircraft ATC DL application includes current position information with the 
MAYDAY report. The sending of MAYDAY automatically causes ADS to be put into the 
Emergency mode. The flight crew may also put ADS into Emergency mode independent of 
transmission of an ATC MAYDAY Report. 

The flight crew can also send a PAN PAN PAN message. 


This paragraph describes the implementation to be used by the FAA ODL. 

This is not to say that the ATC Facility can initiate the ADS Emergency mode of operation. 
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When the ADS emergency mode is activated, all existing connections will be assigned emergency 
periodic contracts. The reporting interval of an existing periodic contract is maintained; new 
default periodic contracts receive an interval of 304 seconds. Periodic reports are tagged as 
emergency reports and the only on-request groups which are sent are the Flight Identification and 
Earth Reference groups in every fifth report 

The ATC Facility can cancel or modify the emergency contract reporting interval and data. The 
ATC Facility may also cancel the emergency mode for its own connection; this in itself does not 
change the reporting rate or report contents. Each ATC Facility should maintain its ADS reporting 
rate at the minimum rate which is necessary. 

6.10 FANS 1 OPERATIONAL ASSUMPTIONS FOR FUNCTIONAL HAZARD 

ANALYSIS 

The 757/767 Functional Hazard Analysis (FHA) has made certain assumptions about the 
environment in which FANS 1 is to be operated. These assumptions are contained here as 
requirements which should be verified (in systems or procedures) before operational approval of 
this FANS 1 System. The following table lists the safety requirements which were considered as 
assumptions in developing the FHA. 

1. All voice communication capability will be retained (HF, VHF, SATCOM) and would be 
considered as a backup to the data link functionality. There will be no proposed change to 
the Master Minimum Equipment List (MMEL) for HF or VHF communication equipment based 
on the initial FANS 1 certification. 

2. There will be established procedures for each communication failure condition. The 
procedures must account for possible loss of messages and indicate how long a pilot or 
controller should wait before deciding a message has been lost. The time-out value must be 
small enough to assure adequate reaction time based on the separation minima. 

3. Air Traffic Control procedures will use ADS periodic reporting or manual ATC DL position 
reports in addition to ARMed reports and/or ADS Event reports. 

4. ATC procedures will be established which will not allow the controller to issue clearances to a 
plane which is not in his area of control. 

5. ATC procedures, systems and personnel will not use AOC DL. 

6. If the printer is certified to DO-178B, level D or is non-essential, confirm print-only data using 
some other means, or do not use print-only data for those data which could contribute to a 
MAJOR failure effect. 

7. If the printer is certified to DO-178B, level D or is non-essential, ATC clearance data received 
through the ATC DL Application which can only be viewed on the cockpit printer must be 
independently verified per approved operational procedures. 

8. The crew shall reject clearances with which they cannot comply and current air traffic 
procedures will be used to resolve any resultant conflicts. 

9. The ATC Facility shall have the means to detect an erroneous flight identifier or tail number 
(aircraft registration) received in the end system (CRC'd) portion of the AFN logon message. 

7.0 DESCRIPTION OF ENVIRONMENTS 

The purpose of this section is to provide a description of the environments (Figure 1) in which this 
end-to-end system will be operating. Sections 7.1, 7.2, and 7.3 describe the airplane, satellite and 
ground environments into which the ATS functions will be integrated. 
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7.1 AIRPLANE ENVIRONMENT 

The 757 and 767 airplanes contain a digital network based on the ARINC 429 protocol. Several 
airplane systems are directly involved with the ATS datalink function. 

A description is provided of the number of systems installed, their procurement type (SFE - Seller 
Furnished Equipment built to a Boeing Specification or BFE - Buyer Furnished Equipment 
procured directly by the airline), criticality, and whether they have an operational interface to 
systems outside of the airplane environment. Then a high level description of each piece of 
equipment is provided including any crew annunciations which the equipment provides. 

It should be noted that there are differences between airline configurations. These differences are 
due to airline options with: 

• Cockpit switching 

• Multiple equipment installation (e.g., 1 versus 2 ACARS MUs) 

• BFE Equipment selection 

The BFE equipment selection probably has the most impact, as the airline is in control of the 
specification and can customize the unit to closely meet its needs. There are variations in the 
levels of conformance or interpretation of the industry standards (i.e., ARINC Characteristics). 

The following systems on 757 and 767 airplanes are involved with the ATS Functions: 


System 

Number 

Installed 

BFE / 
SFE 

Criticality 

External Interface 

Flight Management Computer 

2 

SFE 

Essential 

None 

Multipurpose Control Display 

Unit 

2 

SFE 

Essential 

None 

Aircraft Communication 
Addressing and Reporting 
System Management Unit 

1 or 2 

BFE 

Non-Essential 

None 

VHF Radio 

3 

BFE 

Essential 

Antenna 

SATCOM 

1 or 2 

BFE 

Non-Essential 

Antenna 

Printer 

1 

BFE 

Non-Essential 

Paper 

Warning Electronics Unit 

1 

SFE 

Essential 

Aural 

Engine Indicating and Crew 
Alerting System 

2 

SFE 

Critical 

None 


7.1.1 FLIGHT MANAGEMENT COMPUTER SYSTEM 

The Flight Management Computer System (FMCS) hardware consists of two Flight Management 
Computers (FMCs) and two Control Display Units (CDUs). The FMCs are the main computer 
processors; the CDUs are the interface between the pilot and the FMC. 

The FMCS integrates information from the air data system, inertial reference system, GNSSUs, 
ACARS MU, radio navigation system, mode control panel, engine and fuel sensors, Thrust 
Management Computer (TMC), digital clocks, and crew-entered data to perform the following 
functions: 
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• Navigation 

• Flight Plan Management 

• Guidance and Control 

• Optimized Performance Management 

• Throttle Control 

• Navigation Display 

• Alternate Navigation via the CDU 

• Fault and Configuration Management 

• Airline Operational Communication (AOC) [FANS 1] 

• ATC Datalink [FANS 1] 

• Automatic Dependent Surveillance [FANS 1] 

• ATS Facilities Notification [FANS 1] 

The FMC also utilizes two internal data bases: navigational and performance/engine. ARINC 702 
is used as a guide for design. 

While there are two FMCs installed in the airplane, only one of them provides guidance and 
control at any given time, as determined by the autopilot selection (Left or Center A/P in CMD will 
make the left FMC master, Right A/P in CMD will make the R-FMC the master) or the Navigation 
source select switches. Independent navigation stations from both FMCs are generated for the 
map display. Failure of either FMC is annunciated by an EICAS advisory message 

Failure of the Spare FMC has no impact on the datalink connections. If the Master FMC fails, the 
other FMC which has been kept updated concerning the ATS functions and status, automatically 
takes over the ATS functions with no crew intervention. Messages in the process of being sent to 
the MU at the time of Datalink Master substitution are re-processed by the new master. 
Messages in the process of being received from the MU are not acknowledged and the MU re¬ 
sends the message. 

A modification was made to the CDUs to add an ATC mode key which provides access to the 
FMC ATS functions. 

7.1.2 AIRCRAFT COMMUNICATIONS ADDRESSING AND REPORTING SYSTEM 

(ACARS) MANAGEMENT UNIT (MU) 

The airborne ACARS system is comprised of an ACARS BFE management unit (MU). 
Implementations generally conform to ARINC 724B, 618 and 619. Typically, the MU is connected 
to the following devices: 

• Multipurpose Control Display Units 

• Multi-Input Printer 

• Center VHF 

• SATCOM Satellite Data Unit 

• Aircraft Condition and Monitoring System (ACMS) 

• Central Maintenance Computer 

• Crew Alerting System 

• Flight Management Computer System 

• Airborne Data Loader 

Some airplanes may be configured with two MUs. Some airplanes may be configured with a 
switch to allow use of the center or right VHF radio. It is possible that some airplanes will have 
dual SATCOM as well. In any case, the redundant architecture may contribute to the availability 
of the ACARS. 
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The ACARS MU can interface with the pilot directly through an CDU interface, or through the 
printer interface. Other messages can be exchanged with the ACMS, CMC and FMCS. Some 
messages require pilot interaction, but automatically triggered messages and ground initiated 
messages are possible as well. 

ACARS equipment failures are annunciated on the EICAS system as an advisory message. If an 
ACARS MU should fail, all messages in the process of being transmitted to the FMC at the time of 
failure are lost. ED If the FMC was transmitting a downlink at the time of an MU failure, the FMC 
detects the failure via the lack of positive status from the MU. 

Each unique ACARS part number is considered a different configuration and as such, 
performance of each unique combination needs to be established. 

7.1.3 WARNING ELECTRONICS UNIT (WEU) 

The Warning Electronic Unit (WEU) is a single cardfile that contains electronic cards which 
perform the following essential functions: Stall warning, configuration warning (takeoff and 
landing), altitude alert, speed brake alert, illumination of the master warning lights, generation of 
all aurals in the flight deck, and activation of the stick shaker motors. 

The cards installed in the WEU cardfile are:1 takeoff configuration warning card, 1 landing 
configuration warning card, left and right stall warning cards, 1 altitude alert card, left and right 
power supply cards, left and right siren/owl aural warning cards, 1 bell/chime aural warning card, 1 
signal consolidation card, 1 WEU BITE module, and 1 master warning card. 

7.1.4 VHF RADIO 

Three independent VHF systems (radios and antennas) are installed on the airplane to provide 
line of sight voice and data communication. Typical enroute range of 200 nm can be expected. 
The left and right VHF radios are typically reserved for voice communications, while the center 
radio is typically shared between voice and data communications. 

The MU interfaces with an ARINC 716 radio using the following signals: 

• AUDIO DATA IN 

• AUDIO DATA OUT 

• DATA FREQUENCY 

• DATA KEYLINE 

• VOICE/DATA DISCRETE 

• PORT SELECT DISCRETE 

When the MU is in data mode, the VOICE/DATA and PORT SELECT discretes are grounded and 
the VHF radio is tuned by MU ARINC 429 broadcast data. The radio is keyed by the MU closing 
the data keyline. MSK modulated data received on the selected data frequency is sent to the MU. 
The MU demodulates the data to determine whether a valid uplink is present (UBI present), and if 
an uplink is intended for that MU (matching flight ID or registration number). The MU modulates 
the data prior to presenting the MSK modulated audio signal to the radio. The VHF system does 
not assert possible failure conditions. Therefore, crew alerting for VHF system related failures is 
not possible. 

7.1.5 SATCOM 


This assumes a single MU installation. 
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Satellite communications (SATCOM) may be provided for remote communications where 
terrestrial contact is unavailable, or by airline policy regardless of the state of other communication 
capabilities. SATCOM offers packet data services capable of processing ACARS messages. 
INMARSAT ACARS packet data services are described as data level 2. SATCOM may provide 
other services such as cockpit voice, cabin telephone services, and even passenger facsimile 
services. Each of these services is provided in a manner such that safety services are processed 
in priority over other traffic. However, all ACARS messages are processed equally over 
SATCOM. Once a message is accepted from the MU, no further messages are accepted until 
the satellite ground earth station (GES) acknowledges receipt of the message (which should not 
be confused with the ACARS network acknowledgment). 

Some typical messages that have priority over ACARS messages are listed below: 

• System essential signaling (logon) 

• T channel request and assignment signaling 

• C channel request and assignment signaling 

The transmission of higher priority information over ACARS is necessary to provide a balanced 
service to all the users of the SATCOM system. The ATS ACARS messages are handled 
interchangeably with AOC or AAC ACARS messages. In addition, adequate system bandwidth 
assures rapid transmission of data without excess delay in any case. 

The airborne earth station (AES) is made up of some or all of the following components: 

• Satellite Data Unit (SDU) 

• Radio Frequency Unit (RFU) 

• Class C High Power Amplifier (HPA-C) 

• Class A High Power Amplifier (HPA-A) 

• Low gain antenna (LGA) 

• High gain antenna (HGA) 

• Low noise amplifier/diplexer 

• RF combiners, splitters, and relays 

The AES establishes a logon with a preferred GES by listening on the GES P channel. The 
selection of GES preference is based on programmed airline preferences, or stored or received 
comprehensive frequency tables. The AES establishes communications by data packets 
transmitted on the R and T channels. Data rates are a function of INMARSAT frequency 
assignment, and GES and AES equipage. Data rates in wide use today are effectively 300 bits 
per second, but growth to 600 or even 5250 bits per second is likely. 

The use of SATCOM for voice, circuit mode data, and high speed packet data requires an HGA. 

The HGA is a phased array electrically steerable with a typical gain of 12 dBi. However, when the 

antenna steering required to maintain contact through a particular satellite requires the use of 
non-optimum beams, the effective gain is reduced. If the antenna reports less than 7 dBi gain, 
the AES must cease transmissions and search for another satellite, or wait until conditions 
improve with respect to the current satellite. 

It is possible that the AES may be programmed to switch to the LGA, if installed, while the HGA is 
not available, to maintain contact. It is likely that the LGA is capable of maintaining data contact in 
conditions where the HGA is not. It is possible to program the AES to switch to the LGA if contact 
is not established through the HGA when the conditions for the HGA are expected to be 
acceptable. All current SATCOMs switch to the LGA only if the HGA reports a failure. 
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Each GES maintains a high gain link with the satellite in use. Each GES monitors the 
transmissions from all other GESs using the satellite in use, providing some limited inter-GES 
internetworking. The satellite acts as a transponder, translating the AES to satellite L-band 
communications into satellite to GES C-band communications. Each GES is connected to a 
single ACARS data link service provider. The data link service provider may have a separate 
SATCOM processor to collect both data and logon status, prior to passing data to the service 
provider's main ACARS system processor. 

7.1.6 PRINTER 

This optional printer is controlled by ARINC 740/744 and is installed in the center aisle stand. 
ARINC 740 describes the characteristics of a multiple input printer with a narrow carriage (40 
characters). The ARINC 744 specification describes a wide carriage printer. This printer is 
interfaced with the ACARS, ACMS, FMCS [FANS 1] and CMC systems. 

Appropriate status for printer states (ready, fail, busy, error) is available on the FMC CDU pages 
which provide printer interface capability. 

7.1.7 ENGINE INDICATING AND CREW ALERTING SYSTEM (EICAS) 

The Engine Indicating and Crew Alerting System is composed of two EICAS computers, Display 
Select Panel (DSP), Maintenance Control Panel, and two Display Units. This system provides the 
display of engine primary and secondary indications; display of warning, caution, advisory, 
communication, status and maintenance messages; and the display of maintenance information. 

For the ATS function, additional processing and a new ARINC 429 interface to the FMC have 
been added to provide the "• ATC" communication level message. The EICAS also has an 
additional analog discrete output to drive the chime for the "• ATC" message. 

The FANS-1 upgrade includes new EICAS crew alerting capability for ACARS and SATCOM in 
the form of advisory, comm, and status messages as described below: 
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Text 


Reason 

DATALINK 

LOST 

Advisory 

ACARS NOCOMM 

DATALINK SYS 


ACARS MU failed 

SATCOM 

HH 

SATCOM function failed 

SATVOICE 

LOST 

Advisory 

(optional) 

SATCOM voice system logged off 

SATCOM 

VOICE 

Advisory 

SATCOM voice system failed 

SATCOM 

DATALINK 

Advisory 


•DATALINK 

AVAIL 

Comm Low 
(Optional) 

ACARS regained COMM 

•VHF DATA 
OFF 

Comm Low 
(Optional) 

ACARS VHF voice mode 

•ACARS 

Comm Low and 
Medium 

Flight crew should look at ACARS CDU menus 

•ATC 

Comm Medium 

ATC uplink received 

•FMC 

Comm Medium 

FMC company uplink received 

•PRINTER 

Comm Medium 
or Low 

Uplink message (non-FMC) printed 

•SATVOICE 

AVAIL 

Comm Low 
(optional) 

SATCOM voice system logged on after being unavailable 

•SATCOM 

MESSAGE 

Comm 

Medium 

(optional) 

Flight crew should look at SATCOM CDU menus 

DATA LINK 

SYS 

Status 

ACARS MU failed 

SATCOM 

DATA 

Status 

ACARS/SATCOM interface failed 

SATCOM 

SYSTEM 

Status 

SATCOM System failed 

SATCOM 

HIGH GAIN 

Status 

SATCOM high gain antenna failed 

SATCOM 

LOW GAIN 

Status 

SATCOM low gain antenna failed 


7.2 SATELLITE ENVIRONMENT 

INMARSAT operates a satellite constellation that provides world-wide coverage up to about 75 
degrees of latitude. There are four geostationary positions. At each position, INMARSAT has 
placed a primary INMARSAT-II satellite, operating with global beams. In 1996, INMARSAT will 
add INMARSAT-III satellites, which provide spot beams. There are backup satellites at each 
orbital position. 

Each GES uplinks satellite signal units on P channels. The AES downlinks satellite signal units on 
R and T channels. All circuit mode services are established with data link transmissions, followed 
by dedicated C channel assignment as needed. 
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System performance is affected by the level of traffic and the available RF link margin. In 
addition, the number of channels available, and the speed at which they operate, can significantly 
contribute to overall throughput. The use of special protocols may also enhance system operation 
in the future. 

There may be other satellite operators that wish to process the FANS 1 data. The SATCOM 
avionics are specifically developed to be compatible with the INMARSAT system definition manual 
(SDM). Other satellite operators must ensure compatibility with existing avionics. It is not 
practical to develop regional satellite avionics. 

7.3 GROUND ENVIRONMENT 

This environment includes the remote VHF transceivers (RGS), satellite ground earth stations 
(GES), air/ground message processors, ground routers and the ground-ground links between 
ATC Facilities. The link between the RGS or GES and the ATC Facility is variable depending on 
the ATC Facility. This pathway can be either dedicated or leased lines to the datalink service 
provider, or the ATC Facility may be connected through its own datalink network (i.e., the ATC 
Facility be its own data link service provider). 

7.3.1 NETWORK SERVICE PROVIDER 

The network Service Providers operate networks of VHF transceivers and/or satellite ground 
stations which are the access points to the ACARS network system for the user aircraft. The 
ground stations are connected to an air-ground message processor which is the access point to 
the ACARS network service for all ground systems. The network Service Provider also provides 
automatic direction of uplink messages to the proper network and VHF/SATCOM selection. For 
the purposes of this document, downlink message routing after receipt by the ground station is 
assumed to be the responsibility of the network Service Provider. 

7.3.2 AIR-GROUND INTERFACE 

The Air-Ground communications are supported by three main elements: the avionics, the air- 
ground facilities (i.e.; RGSs and GESs) and the Datalink Service Processor (DSP). 

The DSP provides a gateway/routing function which: 

• Supports the ACARS protocol between itself and the Airborne 
Communications Management Function 

• Provides an interface to the RGSs and GESs 

• Provides aircraft tracking 

• Converts messages from ACARS format to the ATA/IATA ground- 
ground format and 

• Provides an interface to the ground network. 

The Ground Network provides fixed point-to-point messaging. 

7.3.2.1 DOWNLINK MESSAGE FLOW 

On the ground, messages are received by either an RGS or a GES which forward the messages 
to the DSP. They also perform some minor processing. One important function being to facilitate 
'tracking' by adding the identity of the receiving RGS or GES to the message. 
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Upon receiving a message, the DSP 'handshakes' with the aircraft Communications Management 
function according to the ACARS air-ground protocol. The DSP then performs a number of 
functions on the received message. It records the identity of the receiving GES or RGS against 
the aircraft registration for 'tracking' purposes. It converts the message from ACARS air-ground 
format to ATA/IATA ground-ground format. The aircraft registration is re-located within the 
message and the label/sub-label is converted to an equivalent identifier, called an SMI. 

To properly deliver the message, the DSP does a number of things. First the DSP identifies the 
message as an ATS message; the DSP uses the MFI or label to do this. Once identified as an 
ATS message, the DSP looks to the 'supplementary address' field of the message to find the 
ground delivery address (inserted by the aircraft).^ This address is then placed in the header of 
the converted ground/ground message. The message is then routed to this address. 

7.3.2.2 UPLINK MESSAGE FLOW 

The ATC Facility delivers messages to the DSP in ATA/IATA ground-ground format. To assure 
proper delivery to and within the aircraft, the message also contains ACARS and 622 information, 
such as the aircraft registration, an SMI and an MFI, if needed. This information is used to identify 
the aircraft, the aircraft device and the application being addressed, respectively. 

The DSP converts the message to ACARS air-ground format. Part of this involves relocating the 
aircraft registration and converting the SMI to the equivalent label/sub-label combination. To 
deliver the message to the aircraft the DSP selects the appropriate air-ground facility. 

Aircraft 'tracking' provides a list of the most recently used air-ground facilities. The DSP first 
attempts delivery via the last facility used. Should that attempt fail it makes a determination as to 
which facility to use based on the remaining 'tracking' information. 

Once an air-ground facility has been chosen by the DSP, it transmits the message to the aircraft 
via that facility. Communications between the DSP and the aircraft take place using the ACARS 
air-ground protocol. 

RGSs act as little more than remote VHF transceivers connected to the DSP whereas the GESs 
use a "link-layer" protocol for communication between themselves and the aircraft. 

7.3.2.3 ACARS AIR-GROUND PROTOCOL 

Regardless of the media used, all FANS-1 communication uses the ACARS air-ground protocol. 
This protocol operates between the airborne Communications Management function and the 
Service Provider's DSP. 

Messages greater than 220 characters are termed 'multi-block' messages. That is, they are 
divided into 'blocks' no greater than 220 characters in size. Each 'block' then becomes an 
individual transmission on the air-ground subnetwork. 

The ACARS air-ground protocol is a CSMA protocol with a window size of 1, which uses a simplex 
channel. In simple terms this means that if the VHF channel is in use then access is denied but 
when clear then all users may access it. An ACARS block must be acknowledged before another 
ACARS block can be transmitted. Transmission cannot occur if a block is being received. 


Most ACARS messages today only require delivery to the airline host computer, to do this 
the DSP usually uses the aircraft registration. Copies of these messages are delivered to 
supplementary addresses if they are included in the message. ATS messages will 
(normally) only require delivery to the supplementary address (i.e.; the CAA). To 
accommodate this the DSP will be configured to recognize ATS messages and to limit 
delivery to the supplementary address. 
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For the remainder of this section the word "message' refers to an 'ACARS air-ground message' 
i.e.: application data within an ACARS air-ground envelope. 

All ACARS message headers contain the aircraft registration, a technical acknowledgment field 
and an up/downlink block identifier (UBI/DBI). Messages are acknowledged by other messages 
with a Technical Acknowledgment set to the Block Identifier value used in the message being 
acknowledged. A negative acknowledgment is indicated by a special character. If either the DSP 
or the airborne Communications Management function has no data to send but must 
acknowledge a received message, it sends a 'general service message' with the appropriate 
Technical Ack. 

All ACARS messages have a Block Check Sequence (BCS) appended to them for error checking 
purposes. 

The following descriptions apply to the "clear sky" case, where the selected communications path 
is available. The means of selecting appropriate paths for communication are described in 
another section. 

7.3.2.3.1 UPLINK TRANSMISSION 

Uplink transmission from the ATC Facility to the Airborne ATS application system is depicted in 
Figure 5. 

For each message transmitted, the DSP sets a NO ACK timer. One of three things may then 
happen: 


• A message is received with a technical acknowledgment 
corresponding to the UBI used in the uplink message. The 
transmission is considered successful and the UBI is incremented for 
the next message. 

• The DSP receives a message with a negative acknowledgment 
(NACK). The transmission is considered to have failed and a re-try is 
attempted. There may be three re-tries. 

• The NO ACK timer expires and no acknowledgment has been 
received. The transmission is considered to have failed and a re-try is 
attempted. There may be three re-tries. 

Once the NO ACK timer expires and none of the retries have been acknowledged, the DSP 
should route the message via an alternate media (such as SATCOM) or to another service 
provider using internetworking. If all attempts via all means are unsuccessful, the service provider 
originally receiving the uplink notifies the originator of the message that the message was not 
delivered. The service provider then purges the message. 

This block diagram depicts an end-to-end uplink procedure, specifically for the ATS Application 
System residing in an ACARS peripheral and the Communication Management Function in an 
ACARS MU. A different aircraft architecture (e.g., with the ATS Application System and 
Communication Management Function residing in the same unit) would be effectively the same 
from the ground station’s perspective. 
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Figure 5 - Uplinks 


Step 

Description 

1 

ATC sends message to SP 

2 

SP sends message ACK to ATC [SP returns msg with reason if uplink cannot be 
formatted] 

3 

SP breaks message into blocks if necessary, then sends block to Airborne 

Communications Management function 

4 

Airborne Communications Management function sends block ACKs to SP [Airborne 
Communications Management function sends NAK if BCS fails] 

5 

Airborne Communications Management function re-assembles blocks if message is a 
multi-block message, then sends LDuF^lo Airborne ATS application system 
[Airborne Communications Management function sends reject to SP if uplink is 
undeliverable] 

6 

Airborne ATS application system sends link layer ACK to Airborne Communications 
Management function 

[Airborne ATS application system sends NAK if CRC fails or if the msg is larger than 2 

LDUs] 

7 

SP sends MAS to ATC after all blocks are ACK'd by the Airborne Communications 
Management Function. [SP returns msg with reason if uplink was undeliverable] 


7.3.2.3.2 DOWNLINK TRANSMISSION 

The procedures for downlink transmissions from an airborne ATS application to an ATC Facility 
are depicted in Figure 6, and are similar to those for uplinks with the following exceptions: 


The Airborne Communications Management function may retry a 
message if the NO ACK timer expires. The timer is programmed 
differently depending upon whether the Airborne Communications 
Management function is using VHF or SATCOM, and depending upon 
the service provider. For example, in ARINC VHF, typically retries are 
between 10-25 seconds, whereas with SITA VHF, the retries are 


Link Data Unit (LDU) is the packet used between an ACARS MU and an ACARS 
peripheral. 
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between 6-15 seconds. SATCOM retries are 180 seconds apart for 
the first two attempts, then the Airborne Communications 
Management function artificially declares the SATCOM to be NO 
COMM for 600 seconds before attempting a downlink again. The NO 
ACK timer is reset if an uplink is received. 

There are no less than two and no more than seven re-tries. 



Figure 6 - Downlinks 


Step 

Description 

1 

Airborne ATS application system breaks message into LDUs if necessary, then sends 

LDU to Airborne Communications Management function 

2 

Airborne Communications Management function sends link layer ACK to Airborne ATS 
application system [Airborne Communications Management function sends NAK to 

Airborne ATS application system if CRC fails] 

3 

Airborne Communications Management function combines LDUs if necessary, divides 
message into blocks, then sends block to SP (Note: The Airborne Communications 
Management function continues to send the message until the SP responds.) 

4 

SP sends block ACK to Airborne Communications Management function [SP sends NAK 
or no response if BCS fails] 

5 

Airborne Communications Management function sends network ACK to Airborne ATS 
application system when ACK for last block received 

6 

SP sends message to ATC 

7 

ATC sends ACK to SP 


7.3.2.3.3 ERROR CHECKING 

The receiver of an ACARS message (i.e.; MU or DSP) always verifies the integrity of the received 
message by checking each character for parity errors and then checking the entire message 
using the BCS appended to each message. If a message fails the BCS check, the message will 
be discarded. 

Messages in which errors are detected are discarded by the DSP (awaiting re transmission by the 
sender once the No ACK timer expires) however errors detected by an Airborne Communications 
Management function are responded to with a NACK. Downlink messages which cannot be 
formatted are responded to with an ACK but are not passed on. Messages with any of the 
following cannot be formatted: 


Rev: B 


D926T0280 


57 


























• Unknown label 

• Unknown sublabel 

• Unknown agency 

• Unknown format 

• No address 

7.3.2.3.4 CATEGORIES OF OPERATION 

There are two categories of operation for VHF ACARS: Category A, used by ARINC and Category 
B used by SITA. Satellite communications is treated as a special case of Category A. Switch-over 
between the VHF and satellite media is discussed in sections 7.3.2.6 and 7.3.3. 

The main differences between the categories are in their handling of downlink messages. 

With Category A, all RGSs within range of an aircraft receive the transmitted message and on- 
forward it to the DSP. Received signal quality derived from the downlink is then used in selecting 
the RGS for any uplinks including Acknowledgments. 

With Category B, downlink messages are addressed to a particular RGS. The Airborne 
Communications Management function obtains RGS addresses from regular transmissions 
known as a "squitters", which are provided by each RGS for acquisition and identification 
purposes. 

For satellite communications, the task of acquiring a suitable GES for communication is handled 
by the SDU. As no special addressing is required by the MU, satellite communications appear (to 
the MU) as Category A. 

Most ACARS MU can operate with both Category A and Category B networks. 

7.3.2.4 THE DSP - RGS INTERFACE - SITA 

Early SITA RGSs were connected to the DSP using the proprietary character-oriented network 
known as the DTN. The connection between the RGS and the network used a proprietary 
(character-oriented) protocol, known as P1024C. This is one of a family of Synchronous Link 
Control (SLC) protocols, in which the remote device, the RGS, is polled for data by the network 
node. 

The network itself is hierarchical in nature, to deliver messages: 

• Network nodes pass data to concentrators, 

• Concentrators pass data to switches, 

• Switches pass data to other switches , 

• Switches then pass data to concentrators and 

• Concentrators pass data to nodes for final delivery. 

Communication between each set of devices uses a slightly different protocol. Each protocol is 
one of the SLC family and provides message protection through the use of a 16-bit CRC. Note 
that overall protection is provided by the overlaid ACARS protocol. 

New SITA RGSs come equipped with an X.25 interface. Connections between them and the DSP 
are made using SITA's OSI compliant network known as the Mega Transport Network (MTN). 
With X.25, data transmission does not depend on polling by the network. 

7.3.2.5 THE GES - DSP INTERFACE 

7.3.2.5A THE GES - DSP INTERFACE - SITA 
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For connection to terrestrial networks, GESs provide an X.75 interface. 

The connection to the DSP is made using SITA's X.25 network (MTN), providing highly redundant 
connectivity to the DSP. 

Different X.25 networks are linked using the X.75 standard. In this case the Aeronautical Mobile 
Satellite System (AMSS) system represents one network and the terrestrial system(s) represent 
another. 

7.3.2.5B THE GES - DSP INTERFACE - ARINC 

ARINC RGSs are connected to the DSP via a proprietary character-oriented network known as 
ADNS. The connection uses an Synchronous Link Control Protocol (SLC) protocol. The protocol 
uses a 16-bit CRC to ensure message integrity. Overall transmission is in accordance with the 
ACARS protocol. 

Next generation ARINC RGSs will be equipped with an X.25 interface and connected to the DSP 
via an Open System Interconnect (OSI) compliant network known as the ARINC Packet Network 
(APN). 

The GESs provide an X.75 interface to ARINC's Air/Ground Intermediate System (AGIS). AGIS is 
connected to the DSP using an SLC protocol. Overall transmission is in accordance with the 
ACARS protocol. 

7.3.2.6 VHF/SATCOM SELECTION 

Each service provider uses different methods of selecting the data link medium for unsolicited 
uplinks. Typically, all uplinks are routed to VHF, if VHF is available. However, it is possible for a 
message to be routed to SATCOM, if the last downlink were heard over SATCOM. 

7.3.3 INTERNETWORKING 

Internetworking refers to the agreements between service providers to forward each other's ATS 

messages. Internetworking allows seamless access between aircraft and ATC Facilities for ATS 
datalink applications. 

7.3.3.1 DOWNLINK INTERNETWORKING 

The aircraft shall downlink ATC messages over VHF if available, or else over SATCOM if 
available. The DSP receiving the ATC downlink shall deliver the downlink message to the ATC 
address contained in the message. If the DSP receiving the downlink is not connected to the ATC 
system addressed in the downlink, the DSP shall forward (internetwork) the ATC downlink to the 
DSP which has a connection to the addressed ATC system. 

7.3.3.2 UPLINK INTERNETWORKING 

The ATC Center shall send aircraft uplinks to the DSP with which it is contracted. That DSP shall 
determine if the addressed aircraft is active on its network. The DSP shall attempt ATC uplink 
delivery on an active medium until successfully delivered, via VHF, then SATCOM if necessary. If 
the addressed aircraft is not active in the DSP table or uplink delivery attempts on each approved 
active media are unsuccessful, the ATC uplink shall be forwarded (internetworked) to another 
DSP for delivery. 

7.3.4 ATC FACILITY APPLICATIONS 
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The ATS Facility applications are the peers of the airborne ATS application systems. The 
airborne ATS application systems (such as AFN) communicate through the datalink with their 
ground based ATS application system partners. 

The ATC Facility performs the following functions: 

• Provides automatic or manual means of initiating communication, as 
appropriate for application, with individual aircraft; 

• Provides automatic or manual means of terminating communication, 
as appropriate for application, with individual aircraft; 

• Monitors communication link status and transactions for multiple 
aircraft; 

• Decodes downlink messages and extracts received data for controller 
display or internal processing; 

• Provides a means for ATS to compose messages and encode 
uplinks; 

• Provides a means of displaying ADS position reports, waypoint reports 
and flight plan tracks to facilitate the provision of Air Traffic 
Management services; and 

• Detects and annunciates uplink failures and/or downlink messages 
received in error, as necessary. 

The ATC Facility supports operations appropriate to the air traffic environment. Air traffic 
environments can be divided into surface, terminal, en route (domestic) and oceanic. Oceanic 
ATC activities include: pre-departure review and approval, FIR entry/exit coordination, providing 
ATC-initiated clearances and advisories, processing and responding to pilot requested clearances 
and advisories, handling pop-up aircraft, and processing compulsory aircraft position reports. 

7.3.5 ATS GROUND TO GROUND COMMUNICATION 

ATC Facilities communicate today in their handling of traffic which transits their service areas. 
The procedures which govern this communication will have to change to accommodate the 
implementation of a FANS environment. Currently, communication can be controller to controller, 
but with increasing automation, the communication will become ATC Facility to ATC Facility 
through a digital network. 

8.0 ALLOCATION OF REQUIREMENTS TO ENVIRONMENTS 

The purpose of this section is to define requirements for the ATS functions. It is not the intent of 
this document to repeat existing industry documentation. These requirements are intended to be 
discussed in sufficient detail to: 

• Complete the description of all assumptions to a requirement; 

• Allocate requirements to an environment or environments; and 

• Allocate requirements to individual systems within the airplane 
environment. 

It should be noted that the end-to-end requirements are independent of the data pathways to be 
used by the functions. For example, the requirements for the AFN function are independent of 
whether the communication occurs over the satellite network or the VHF radio network. 
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The following sections list the requirements for each of the functions as they have been allocated 
to the specific environments: airplane, satellite or ground. In the case of the airplane environment, 
the requirements are allocated to the specific airplane subsystems. Any end-to-end performance 
requirements for the function are described along with the rationale for that performance 
requirement. 

8.1 ATS FACILITIES NOTIFICATION FUNCTION (AFN) 

8.1.1 ALLOCATION TO AIRPLANE ENVIRONMENT 

a) The FANS 1 AFN application shall provide the functionality defined by sections 5.1 and shall 
meet the requirements listed below. 

b) This functionality shall be developed to DO-178B Level C or per an equivalent or agreed to 
certification level. 

c) The flight identifier and aircraft registration which the AFN application uses shall be exactly 
the same as the filed flight identifier and aircraft registration. 

d) The AFN application shall include a time stamp in each AFN downlink message, using the 
format and rules defined in section 5.1, whenever time is available. 

e) The AFN application shall not accept an AFN uplink message which contains a flight identifier 
or tail number which does not match the current flight identifier or tail number, respectively. 

f) The AFN application shall accept alpha characters and numerics in ground addresses within 
AFN messages. 

g) The AFN application shall implement the Ti timer defined in section 5.1. 

h) The AFN application shall process an uplink AFN Contact Advisory message, formulate the 
appropriate responses (AFN Response and AFN Contact) and attempt to send the responses 
within 5 minutes. 0 If the corresponding uplink AFN Acknowledgment message is received 
within the T! time, the AFN application shall formulate the appropriate response (AFN 
Complete with reason code as defined in ARINC 622) and attempt to send the response 
within 5 seconds; alternatively, if the AFN Acknowledgment is not received, the AFN 
application shall formulate and attempt to send the AFN Complete message (with reason 
code 1) within 5 seconds of the Ti timer expiration. 

i) The AFN application shall use the version number “01” for the ARINC 745-2 ADS application. 

8.1.2 ALLOCATION TO SATELLITE ENVIRONMENT 

a) There are no AFN function requirements allocated to the Satellite Environment. 

8.1.3 ALLOCATION TO GROUND ENVIRONMENT 

8.1.3.1 ALLOCATION TO SERVICE PROVIDER COMPONENT 


The value of the ground timer is not in accordance with ARINC 622-1. The original Tt 
value of 5 minutes was expanded due to unaccounted delays. The unaccounted delays 
are due to the fact that the AFN Response is sent before the AFN Contact, and the fact 
that AFN messages are lower in priority than ADS and ATC DL messages. 
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a) The datalink service provider shall perform a lookup of the 4-character ICAO (ATC Facility) 
code found in the user address field of a downlink AFN message to determine the 7-character 
network address to be used for routing purposes to a ground AFN application. 

8.1.3.2 ALLOCATION TO ATC FACILITY COMPONENT 

a) An AFN application, compatible to that defined by section 5.1, shall be implemented in the 
ATC Facility. 

b) The ground AFN application shall be developed and modified using standards which provide 
equivalent safety to DO-178B Level C. 

c) The ATC Facility shall coordinate with its service provider to establish its 4-character ICAO 
code identifier for use with the AFN Function (and the ATC DL Function). 

d) The end-to-end Cyclic Redundancy Check (CRC) shall be calculated and verified by the ATC 
Facility to assure required integrity of the downlink AFN transmission. If the CRC check fails, 
the downlink shall be ignored. Similarly, the end-to-end CRC shall be calculated and inserted 
into the uplink AFN transmission. 

e) The ATC Facility shall have an automated means to unambiguously identify an aircraft from 
the flight identifier and tail number (aircraft registration) as contained within the end system 
(CRC'd) portion of the AFN logon messaged! 

f) The ATC Facility shall have the responsibility to assure that the ground application versions 
are compatible with the airplane application versions, as indicated by the airplane AFN logon. 

g) The ATC Facility shall recognize the ADS application version number ‘OT as representing the 
FANS 1 ADS application. The ATC Facility shall recognize the ATC application version 
number ‘OT as representing the FANS 1 ATC DL application. 

h) Routing of a logon message within an ATC Facility (e.g., local control, ground control, etc.) 
shall be the responsibility of that facility. 


27 The intent of this requirement is to mitigate the hazard associated with delivery of a 
clearance to an aircraft other than the one for which it was intended. As such, it is 
incumbant upon the ATS facility to assure that the flight identifier by which an aircraft is 
tracked correlates with the tail number to which uplinked messages are addressed. Two 
options for satisfying this requirement have been suggested. Both options are 
acceptable. 

1. Procedures in the South Pacific currently require aircrews to transmit a position report 
after crossing an FIR boundary or transmitting a new AFN logon. The ATC Facility 
may use this position report to identify an aircraft, as it provides sufficient route 
information to verify that the filed flight plan matches the flight identifier received for 
each aircraft. Since this method does not correlate tail number and flight identifier, the 
ATC Facility must also have a means to prevent establishment of a CPDLC 
connection with an aircraft if that aircraft's tail number is the same as the tail number 
associated with an existing CPDLC connection. 

2. The ATC Facility may opt to compare the end system flight identifier and tail number 
as received in the AFN logon message against those identified in the filed flight plan. 
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i) The ATC Facility shall process the logon message and formulate an appropriate response 
within 3 minutes to assure that the uplink response to a downlink AFN Contact message will 
be received prior to expiration of the aircraft AFN application’s T-i timer. 

j) The ATC Facility shall send a positive response to the aircraft, if ATS will be using ADS and/or 
ATC DL to communicate with the airplane, using the AFN Acknowledgment message (FAK 
MTI followed by reason code set equal to 0). The ATC Facility shall send a negative 
response using the AFN Acknowledgment message (FAK MTI followed by a non-zero reason 
code) if not. 

k) If the ATC Facility uses the AFN Contact Advisory uplink, the facility shall implement the T 2 
and T 3 timers, defined in section 5.1. 


Rev: B 


D926T0280 


63 





8.2 DATALINK 

The detailed requirements for the datalink function are specified below. 

8.2.1 ALLOCATION TO AIRPLANE ENVIRONMENT 

8.2.1.1 FMCS 

a) The following downlink message prioritization scheme shall be implemented in descending 
order of priority: 

• ATC Datalink Messages 

• ADS Messages 

• AFN Messages _ 

• AOC Messages, per ARINC 618 ^1 

b) The FMC shall abort all pending ATC DL downlinks, cancel all ADS contracts and terminate 
all connections after 16 consecutive minutes of NOCOMM, VOICE only, or FAIL. 

c) The FMC shall send the DISCONNECT message defined in ARINC 622-1 in case of an ADS 
request from a 6th ATC Facility and other cases listed in ARINC 622-1. 

d) The FMC shall include the tail number (aircraft registration) in each ATC DL and ADS 
downlink message as described in section 5.2.1. The FMC shall discard an uplink ATC DL 
and ADS message which contains a tail number which does not exactly match the ATS 
FMC’s tail number. 

e) The FMC shall perform the CRC calculation as modified by section 5.2.1. 

8.2.1.2 ACARSMU 

8.2.1.2.1 ACARS MU REQUIREMENTS 

a) The ACARS MU shall conform to ARINC 724B and ARINC 618 with the additional 
requirements specified below. 

b) The ACARS MU shall determine and maintain status alerting during all modes of operation 
whether each sub-network is considered available or not. 

c) The ACARS MU shall respond to the FMC supplied-destination code (G) as defined in ARINC 
724B. 

d) For VHF, the ACARS MU shall consider frequency acquisition (frequency search) to be a VHF 
not available (ARINC 618, section 5.3). ACARS shall downlink an ATS message via 
SATCOM if the primary category B site fails to respond to all downlinks, and shall do so prior 
to searching the alternate sites to establish a new primary category B site. 


The prioritization of ATC DL messages over ADS messages is not in agreement with the 
relative Transport Layer priority requirements cumulatively set forth in DO-219, DO-212 
and ARINC 745. ATC DL is higher priority because its messages may include corrective 
action resulting from analysis of ADS data. Periodic ADS reports from previous 
transmissions allow delays in subsequent ADS reports in the event a corrective action (via 
ATC DL) is necessary the same time an ADS report is required. 
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e) Receipt of any valid uplink block shall stimulate the ACARS MU to downlink a message to 
both verify the integrity of the data link as well as providing a stimulus for the DSP to 
recognize the path to that airplane. The ACARS MU shall not consider itself "IN COMM" until 
it receives an acknowledgment to it's downlink (ARINC 618, section 5.6.2.2). The ACARS MU 
shall declare VHF NOCOMM if a downlink is not acknowledged, and all retries are 
unsuccessful. 

f) The ACARS MU shall consider VHF Voice mode to be a VHF not available state; the ACARS 
MU shall downlink an ATS message via SATCOM, if available. 

g) For SATCOM, the ACARS MU shall first ensure that the SATCOM has declared a data link 
available. If the ACARS MU does not receive an acknowledgment within 180 seconds after 
first sending a message, the ACARS MU shall retransmit the message (ARINC 618, section 
7.7.2, AT7 NO ACK timer). Failure to receive an uplink acknowledgment within 180 seconds 
of transmission of the second downlink attempt shall cause the ACARS MU to declare the 
SATCOM link to be NOCOMM (ARINC 618, section 7.7.2, AT6 NOCOMM timer). A 
SATCOM NOCOMM shall also be declared if SATCOM declares data link not available for 
any period of time, the ACARS MU shall presume the link is "IN COMM" once again if one of 
the following events occur (ARINC 618, section 7.7.5): 


• A valid uplink is received; 

• SATCOM transitions from data link not available to available; or 

• 10 minutes have passed since declaring NOCOMM while the 
SATCOM declares data link available. 

h) The ACARS MU shall send Q0 upon detecting that the SATCOM has logged onf^ 

i) The ACARS MU shall be capable of receiving and acknowledging uplink messages 
concurrently on SATCOM and VHF. The correct order of multi-block uplink messages shall 
be retained (including during a VHF/SATCOM change-over or concurrent use). 

j) The ACARS MU shall complete message transmission over a given subnetwork if possible. If 
the subnetwork connection which The ACARS MU is currently transmitting a message upon is 
lost, the ACARS MU shall re-queue the downlink message when a link is acquired. If the 
subnetwork connection which the ACARS MU is currently receiving a message upon is lost, 
any multi-block uplink in progress shall be treated as an incomplete multi-block uplink. 

k) The ACARS MU shall provide the capability to receive a downlink from the FMC while a 
message from another peripheral is being transmitted. 

l) The ACARS MU shall transmit messages from the FMC, and those created from direct 
interface with the ACARS MU, prior to those from other peripherals. 

m) When an appropriate channel is available, the ACARS MU shall transmit the next highest 
priority message (based on source as defined above) stored in its queue at the time. When 
the FMC has a downlink message which it is attempting to deliver to the ACARS MU, the MU 
should not send any other non-ATS downlink prior to receiving and sending the ATS 
message. 


Any application level message initiated over SATCOM would fulfill this requirement. 
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n) The ACARS MU shall not operate such that a downlink message, with a destination code of 
"V", from one peripheral is able to prevent downlink messages, with a destination code of "S" 
or "G", from other peripherals from being sent. 

o) The ACARS MU shall provide a positive technical acknowledgment to each valid uplink 
(ARINC 618, section 3.2.1). 

p) The ACARS MU shall divide a downlink ATS message into ACARS blocks as necessary, add 
air-ground headers and its own checksum to the ATS message but shall not modify any part 
of the ATS message, beginning with the first byte immediately following the five byte 
Control/Accountability header, through and including, the last byte of the end system 
application CRC. 

q) For an ATS uplink to the FMC, the ACARS MU shall translate the ACARS blocks into a file 
beginning with the first character immediately following the sublabel field. A five byte 
Control/Accountability header shall be added by the ACARS MU to the front of the file and the 
entire file is then transferred to the FMC. 

8.2.1.2.2 ACARS PERFORMANCE ISSUES 

It should be noted, that ACARS protocols as well as specific vendor implementations could 
introduce delays into the ATS end-to-end functions and could restrict the operational benefits. 

The ACARS MU should be capable of interrupting a downlink multi-block message with a higher 
priority, downlink single block message (based on source as defined above). If MU has this 
capability, MU should use true message sequence numbers (instead of the time stamps) to 
ensure detection of incomplete multi-block messages. 

The ACARS MU may alternatively (to nesting) downlink ATS messages via SATCOM if the VHF 
media is busy with lower priority traffic. 

Downlink VHF re-transmission success depends on the DSP in use and ACARS vendor. 
Typically an MU will make a maximum of 6 downlink attempts per block at random intervals of IQ- 
25 seconds for Category A operation. The number of attempts per block and the length of the 
intervals between attempts varies for Category B operation and is dependent upon the number of 
Category B sites being tracked at the time of the downlink. 

Long multi-block uplink and downlink messages should generally be discouraged. If any given 
message source were to launch a 10 block exceedance message, all other traffic (other than 
single blocks if the ACARS MU is able to interleave these) would be held off the channel for 
several minutes during this transaction. 

If the ACARS MU receives an uplink over SATCOM that does not acknowledge a downlink over 
SATCOM (criss-cross situation), the MU should immediately downlink a general response 
acknowledgment of the uplink and not reset the NO ACK timer for the original downlink. 

8.2.1.3 SATCOM 

a) The SATCOM System shall comply with ARINC 741 parts one and two. The SATCOM 
System is considered a pass-through system and it shall not modify any ATS message. 

b) The SATCOM system shall support the alerting messages, described in section 7.1, as 
appropriate to the airplane. If the SATCOM system utilizes a high gain antenna, the SATCOM 
system shall provide for continued data transmission capability if the high gain antenna 
reports less than 7 dBi of gain. The SATCOM may either utilize a separate low gain antenna 
or utilize the high gain antenna as a low gain antenna in this circumstance. 
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8.2.1.4 VHF RADIO 

a) There are no additional requirements beyond compliance to ARINC 716. 

8.2.2 SATELLITE ENVIRONMENT 

a) The current configuration and capability of the Inmarsat II satellites satisfy the requirements 
for ATS Messages. The satellite component is considered a pass-through system and shall 
not modify any ATS message. 

b) Other satellite systems may be used to support the FANS 1 system, but the interfaces with 
the airplane SATCOM system and the ground system must be shown to be interoperable. 

8.2.3 GROUND ENVIRONMENT 

8.2.3.1 VHF SUB-NETWORK COMPONENT 

a) This ground sub-network component is defined by ARINC 618 and no changes are necessary 
to support the implementation of FANS 1. 

8.2.3.2 SERVICE PROVIDER COMPONENT 

a) The ground service provider component is described by ARINC 620 and section 7.3.1 of this 
document. 

b) The service provider shall recognize messages formatted per ARINC 622-1 and section 5.2.1 
of this document as being ATS messages. 

c) The service provider shall use the ACARS tail number in uplink ATS messages to address the 
aircraft. 

d) Service providers shall not modify any ATS message parts, including insertion or addition of 
CR-LF characters, encapsulated by the end system CRC. 

e) Service providers shall provide a positive technical acknowledgment to each valid ATS 
downlink (ARINC 618 section 3.2.2). 

f) Service providers shall forward all ATS messages which have been acknowledged to the 
addressed (as specified in the user address field) ATC Facility. 

g) Service providers shall pass on the User Address Field text, i.e., the MFI and/or destination 
addressFi 

8.2.3.2.1 INTERNETWORKING 

a) Uplinks shall contain the original source address unless they are passed on, in which case 
they shall contain the source router address. Downlinks shall all have the address of the 
router which originally received the downlink.FH 

Given the requirement that ARINC 622 functionality exists in the airplane and in the ATS end 

systems^] 


This was stated at Interoperability Team meeting #4 held on 6/16/94. Note that ARINC 
622-2 section 2.2.1.2 states that SP’s should not pass on the MFI. 

This was stated at Interoperability meeting #5 held on 10/17/94. 
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b) ATC Facilities shall only need to contract with one Datalink Service Provider (DSP) for 
communications access to any FANS 1 aircraft. The contract shall be established with the 
DSP known as the "primary DSP" which will be responsible for internetworking of uplink 
messages to the aircraft. The primary DSP will also play a role in internetworking of downlink 
messages from the aircraft if required. [Note: Downlink messages should be routed to the 
ATC Facility in the most efficient manner. In some cases, downlink messages will not need to 
pass through the primary DSP's network], 

c) ATC Facilities shall not be required to track communication/media usage (not station nor 
SATCOM/VHF nor DSP). 

d) ATC Facilities shall only need to send data link messages to a single address per airplane. 

e) Message assurance shall be provided for uplinks generated by ATC Facilities. 

f) Internetworking transit times shall conform to data link performance parameters in section 
8.2.4. 

g) For uplink messages generated by ATC Facilities: 

• The DSP providing service to the ATC Facility shall first determine if 
the aircraft is active in its own VHF and/or SATCOM activity table. If 
the addressed aircraft is not active in the DSP’s activity table, the 
uplink should be forwarded (internetworked) to another DSP for uplink 
delivery. If the addressed aircraft is active in the DSP’s activity table, 
the DSP shall attempt to deliver the uplink to the aircraft within the 
uplink message delivery performance objective as described in 
Section 8.2.4 Datalink Performance. In order meet the uplink 
message delivery performance objective, it may be necessary for the 
DSP to internetwork to another DSP instead of attempting the uplink 
on all media listed as active. ; 

• If the DSP is unable to deliver the uplink, the DSP shall forward the 
uplink message to another DSP for delivery; 

• If the message is delivered, the delivering DSP shall send the 
message assurance delivery confirmation message to the originating 
address; 

• If the message is not delivered, the last DSP to handle the message 
shall send the message assurance intercept message to the 
originating address. 

8.2.3.2.2 RECORDING OF ATS MESSAGES 

a) All records shall be time stamped with time, to the nearest second. The service provider time 
source shall be within 2 seconds of UTC time. 

b) All records shall allow proper decoding to determine conclusively the data that were expected 
to be transmitted, or actually received. 

c) The data link service provider shall retain the records for at least 30 days. These records 
shall be made available for air safety investigative purposes on demand. 


This assumption and the requirements which follow are based on the Internetworking 
Requirements for ATS SR&O, in Att. G to App. D, in the Final Report of the Seventh 
meeting of the Informal South Pacific ATS Coordinating Group, Nov. 14-18, 1994. 
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d) Each element shall be recorded in order to determine the exact data link operation. 

8.2.3.3 ALLOCATION TO ATC FACILITY COMPONENT 

a) All ATC Facility requirements herein shall apply to an airline facility which implements the ADS 
Function. 

b) The end-to-end Cyclic Redundancy Check (CRC) shall be calculated, as defined in section 
5.2.1, and verified by the ATC Facility to assure required integrity of the downlink ADS and 
ATC DL transmission. Similarly, the end-to-end CRC shall be calculated, as defined in 
section 5.2.1, and inserted into each uplink ADS and ATC DL transmission. 

c) The ATC Facility shall compare the aircraft registration (tail number) in the CRC'd portion of 
each ATC DL and ADS downlink message against the information received in the CRC'd 
portion of the AFN logon message. Neither the ACARS header tail number nor the ACARS 
header flight number shall be used for verification purposes. Error handling procedures shall 
be conducted for an ATC DL and ADS message which is received with an aircraft registration 
which does not correspond with the AFN information. 

d) The ATC Facility shall include the aircraft registration (tail number) in each uplink ADS and 
ATC DL message as described in section 5.2.1. 

e) The ATC Facility shall place only a single ground address in the User Address Field of each 
uplink ADS message. 

f) The ATC Facility shall not modify any ATS messages for avionic display purposes, including 
insertion or addition of CR-LF characters. 

g) The ATC Facility shall include a unique identifier with each uplink message in order that the 
service provider may provide the tracing necessary for Message Assurance (defined in 
ARINC 620). 

h) The ATC Facility shall be connected to a single service provider for uplink message serviceFH 
The ATC Facility may be connected to multiple service providers for downlink message 
service. 

i) The ATC Facility shall include only the AN TEI for uplink aircraft addressing. 

8.2.4 DATALINK PERFORMANCE 

The datalink function can contribute a varying amount of transport delay to the ATS message. 

The contributing factors to that transport delay of a downlink message are as follows: 


An ATC Facility connected to more than one service provider would require additional 
functionality from the service providers to support internetworking. 
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• Time to accept message from ATS application 

• Time message spends in the communication management function’s 
queue while other messages are sent or received 

• Time to establish a valid air-ground connection (VHF or SATCOM) 

• Time to route message to selected data pathway (radio or satellite) 

• Time for the selected transmitter to transmit the message 

• Time to transmit message from ground station to service provider's 
processor 

• Time to route message from service provider to a ground end system 
router 

• Time to route message from ground end system router to application 

There are similar factors contributing to the transport delay of an uplink message. 

The requirements in the following table have been established for FANS-1/A operations in the 
South Pacific^ These requirements address message transit delay, system availability, system 
reliability, and system integrity. It is assumed that similar requirements will be established in other 
operating regions. 


System performance requirements were set using best estimates during implementation 
of FANS-1/A operations in the SOPAC. By September 1998, it was evident that, despite 
the fact that performance requirements were being met, the system was not performing 
well enough to meet operational expectations. As the result of extended discussions 
during the Fourth FIT Meeting in Nadi, Fiji in September, 1998, revised requirements were 
proposed by the FIT. At the subsequent ISPACG meeting in Auckland, New Zealand, in 
December 1998, these recommendations were adopted. 
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Criteria 

Definition 

Values 

Performance 

End to end round trip time for uplinks, (sending and reception 
of MAS) 

Round trip time 
of 2 minutes, 



95% of the 
messages. 



Round trip time 
of 6 minutes, 
99% of the 
messages. 


End to end one way time for downlinks, (comparison of 
message time stamp and receipt time) 

One way time of 

1 minute, 95% of 
the messages. 



One way time of 

3 minutes, 99% 
of the messages 


Uplink messages only: Undelivered messages will be 
determined by: 

• Message assurance failure is received. After trying both 
VHF and SATCOM. Depending on reason code received, 
the message might, in fact, have made it to the aircraft. 

Less than 1% of 
all attempted 
messages 
undelivered 


• No message assurance or flight crew response is received 
by ATSU after 900 seconds 


Availability 

The ability of the network data link service to perform a 
required function under given conditions at a given time: 

99.9% 


The maximum allowed time of continuous unavailability or 
downtime should be declared (MTTR)*: 

TBD 

Reliability 

The ability of a data link application/system to perform a 
required function under given conditions for a given time 
interval: it can be expressed in MTBF (Mean Time Between 
failure) * 

TBD 

Integrity 

The probability of an undetected failure, event or occurrence 
within a given time interval. 

1(T 6 


* Availability = MTBF/(MTBF+MTTR) 
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Datalink Performance Certification vs. Operational Approval 

Datalink performance can affect both the Part 25 Type Certification approval and the Part 121 
operational approval process or other means of obtaining operational authorization. Part 25 
intended function supports Part 121 operational requirements. The operational performance, 
integrity, and availability criteria define the intended function and these criteria will be 
demonstrated during the Part 25 Type Certification airworthiness approval. The Part 25 "intended 
function" for data link with regards to the ATS functions is that the message arrives at the peer 
end system, can be accepted by a peer end system and satisfies the performance criteria above. 
The transport delay of the messages is very important for the operational approval of the 
functions. 

The end-to-end transport delay of ATS communications is extremely dependent on aircraft 
configuration, satellite configuration, ground network configuration, and ATC Facilities. The Part 
25 certification of the 757/767 (Pegasus ‘00) FANS 1 system will include a demonstration of the 
datalink system performance satisfying the performance criteria above. This demonstration will 
be conducted with only one service provider and one ATC Facility, but will satisfy the Part 25 
certification requirements regardless of service provider or ATC Facility. The performance data 
that are collected during the certification will be available to support operational approval with 
other service providers or ATC Facilities. 

8.2.5 DATALINK OPERATIONAL REQUIREMENTS 

a) HF voice shall be maintained as an alternative means of communication. 

b) Procedures to detect the loss of datalink or expected aircraft responses shall be established. 

8.3 AUTOMATIC DEPENDENT SURVEILLANCE (ADS) 

8.3.1 ALLOCATION TO AIRPLANE ENVIRONMENT 

a) The FMC shall provide the ADS Application functionality as defined in section 5.3 and shall 
meet the requirements listed below, to transmit and receive ADS messages over the ACARS 
datalink network. 

b) This function shall be developed to DO-178B Level C or per an equivalent or agreed to 
certification level. 

c) The FMC shall use the ADS Report data content definition contained in Appendix B to this 
document. The accuracy of the ADS Report data content shall match the accuracy of the 
source of the data as specified in Appendix B, limited in some instances by the reduced 
resolution of the ADS formats. 

d) The FMC shall formulate and attempt to send the appropriate ADS response within 5 seconds 
of receipt of an ADS request. The FMC shall formulate and attempt to send the required 
periodic report within 5 seconds of the periodic trigger. The FMC shall formulate and attempt 
to send the appropriate event report within 5 seconds of detecting the event trigger. 

e) When GPS is unavailable, the FMCS shall revert to using the flight deck clock as the time 
source for all FMCS functions, including the ADS application. The Position Determination 
Accuracy portion of the FOM shall be calculated as defined in section 5.3. 

8.3.2 ALLOCATION TO SATELLITE ENVIRONMENT 

a) There are no ADS function requirements allocated to the Satellite Environment. 

8.3.3 ALLOCATION TO GROUND ENVIRONMENT 
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a) All ATC Facility requirements herein, except where related to the usage of five connections, 
shall apply to an airline facility which implements the ADS Function. 

b) An ADS application, compatible to that defined in section 5.3, shall be implemented. 

c) The ground ADS application shall be developed and modified using standards which provide 
equivalent safety to DO-178B Level C. 

d) The ATC Facility shall insert the tail number (aircraft registration) from the CRC'd portion of 
the AFN logon message into the header of all ADS uplinks. 

e) ATC Facilities shall arbitrate amongst themselves the establishment and cancellation of ADS 
connections with the airplanes. This means ATC Facilities use the forwarded flight plan, 
explained in section 6.2.1, to determine when to initiate and terminate ADS contracts for 
airplanes operating within their service volume. For example, the ground application should 
automatically cancel ADS connections or procedures shall be instituted to require ATS to 
manually cancel the connection, when the ADS reports are no longer required for ATS 
purposes. 

f) ATC Facilities shall not request increased rates on aircraft operating in Emergency Mode 
unless they are controlling the aircraft. ATC Facilities shall request a return to normal 
reporting rates as soon as possible after an emergency situation has been declared as a high 
reporting frequency does induce response time delays in the airborne applications 

g) ATC Facilities shall be able to handle non-compulsory reporting points and pilot entered 
waypoints as ADS waypoints (for event reports and for Predicted Route data). 

h) If the aircraft is on an offset and is expected to return to the original flight plan, the ATC 
Facility should exercise discretion in use of the aircraft intent and predicted route group data. 
When an offset is active, the data in these groups will be predicated on continuation of the 
offset. 

i) ATC Facilities shall have a means to assure that requests for periodic reports and demand 
reports are responded to within an adequate time (e.g., timers, procedures, etc.). 

j) ATC Facilities shall not rely solely on ADS event reports to detect violation of separation 
minima. 

8.4 ATC DATALINK (ATC DL) 

8.4.1 ALLOCATION TO AIRPLANE ENVIRONMENT 

a) The FMC shall provide the ATC DL functionality as defined by section 5.4 and shall meet the 
requirements listed below, to transmit and receive ATC DL messages over the ACARS 
datalink network. 

b) This function shall be designed to DO-178B Level C per an equivalent or agreed to 
certification level. 

c) All ATC DL data which could contribute to a major failure effect shall be displayable on a flight 
deck Display Unit. 

d) The FMC shall include the time stamp, defined in section 5.4, in all ATC DL downlink 
messages whenever time is available. The time stamp shall be set to a value which is within 
5 seconds of the time at which the message was initiated. 
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e) A route report or route request shall contain a truncated flight plan (not truncated Route 
Clearance Message variable), if necessary to send an ATC DL message due to message size 
limitations defined in section 5.4. 

f) The ATC DL application shall automatically append message element DEVIATING [direction] 
[distance offset] OF ROUTE (#80) to route related reports if an active lateral offset exists at 
the time the report is generated■F’l (See Appendix A.) 

g) The response to receipt of uplink message element 148, 151 or 152, shall be encoded in free 
text message element (#67), as there are no pre-defined downlink elements which are 
appropriate. (See Appendix A for text of free text messages.) 

h) When a downlink report containing present altitude is sent, the downlink message element 
CLIMBING TO [altitude] (#29) or the downlink message element DESCENDING TO [altitude] 
(#30) shall be automatically attached if appropriate. 

i) The flight crew shall modify data contained in position reports and other route related reports 
such that position reports only contain data relative to the mandatory reporting points. 

j) The FANS 1 ATC DL application shall treat an uplink message which contains the message 
element [track detail msg] (#178) per the DO-219 requirements for handling received 
messages which contain undefined message elements (i.e., the message shall be discarded 
and a downlink error message shall be transmitted). 

8.4.2 ALLOCATION TO SATELLITE ENVIRONMENT 

a) There are no ATC DL function requirements allocated to the Satellite Environment. 

8.4.3 ALLOCATION TO GROUND ENVIRONMENT 

a) An ATC DL application, compatible to that defined in section 5.4, shall be implemented. 

b) The ground ATC DL application shall be developed and modified using standards which 
provide equivalent safety to DO-178B Level C. 

c) The ATC Facility shall insert the tail number (aircraft registration) from the CRC'd portion of 
the AFN logon message into the header of all ATC DL uplinks. 

d) The [icao facility designation] used in the ATC DL uplink Connect Request message shall only 
contain alpha characters!^! 

e) The ATC Facility shall send uplinks to close downlinks for which the airborne ATC DL 
application is waiting for a response. Note that failure to do so may, depending on the aircraft 
model, eventually cause the airborne ATC DL application to exhaust all message identification 
numbers and to terminate the ATC DL connection. 

f) The ATC Facility shall only send characters from within the set as defined in section 5.4. 

g) The ATC Facility shall send uplink message element 143, CONFIRM REQUEST, with the 
reference number of the downlink in question. 


This is in lieu of sending the route data as modified by the offset (as ADS does). 

To facilitate aircraft-initiated logon in case of loss of communications, it is recommended 
that the [icao facility designation] used by an ATC Facility be the same as the 4-character 
ICAO code that the flight crew would use to initiate a logon. 
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h) The ATC Facility shall have the capability to resolve "duplicate waypoint" names which will be 
sent in downlink [route clearance] variables. 

i) The ATC Facility shall include the optional [latitudelongitude] with any [publishedidentifier] for 
which duplicates exist. 

j) The ATC Facility shall be aware that there will be instances of duplicate identifiers within the 
same FMC NDB file. If such a duplicate is uplinked as a [position] in a loadable message 
element, the FMC will select one and load it into the flight plan. When duplicates lie 
geographically close to each other, the selected duplicate may not be the one which was 
intended FH 

k) The ATC Facility shall not send an uplink message containing the message element [track 
detail message] (#178). 

l) When using the [airwayidentifier] variable, the position at which the airplane is to join the 
airway shall be included, encoded as a [publishedidentifier], immediately preceding the 
[airwayidentifier] in the [routeinformation]. In addition, the position at which the airplane is to 
depart the airway shall be included, encoded as a [publishedidentifier], immediately following 
the [airwayidentifier] in the [routeinformation]. 

m) In order to assure that the data are loaded correctly into the flight plan, the following 
constituent variables of the [routeclearance] variable shall not be used with elements 79 or 83: 
airportdeparture, proceduredeparture, procedureapproach, procedurearrival, airwayintercept. 
In addition, the airportdestination variable shall not be used with element 79. 

n) ATC Facilities shall not rely solely on ATC DL "armabl^l 1 reports to detect violation of 
separation minima. 

9.0 POST-CERTIFICATION ACTIVITY 

9.1 OPERATIONAL AUTHORIZATION 

The culmination of FANS 1 development activity is an operational authorization for each airline to 
realize the benefits of the FANS 1 features. The milestones required for each operational 
authorization include a) a Type Certificate for a FANS 1 equipped airplane, b) commissioned ATS 
ground facilities, then c) the operational authorization. 

The first purpose of this section is to suggest the process for commissioning of new ATS facilities 
and for obtaining operational authorizations. Second, this section suggests how changes to the 
ATS function in all environments might be handled. Also, provisions for reporting problems in 
service is discussed. 

Initially, close monitoring of all operational authorizations, commissioning of ATS facilities, new 
procedures, and change activity is necessary to ensure continued safety and interoperability of 
FANS 1 ATS applications and to ensure that the requirements specified in this document are 
correct and complete. 


This is an unavoidable limitation of the DO-219 message set. There is no optional 
[latitudelongitude] for the [position] variable. 

The “armable” reports are elements 28 (LEAVING [altitude]), 31 (PASSING [position]), 37 
(LEVEL [altitude]), and 72 (REACHING [altitude]). 
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This document states (in section 8 and appendix D) the requirements placed upon the ATC facility 
to ensure safety and interoperability which should be satisfied prior to commissioning of a new 
ATS facility. Each new facility should be examined on a case by case basis for conformity to 
these requirements. In cases where the proposed use or implementation is not addressed by this 
document or the facility does not meet these requirements, the differences must be resolved or 
the operational authorization may be limited. 

9.2 CHANGES TO THE ENVIRONMENTS 

The airworthiness approval of the FANS 1 aircraft systems is based on a representative “end-to- 
end” configuration of the ATS functions that is consistent with the requirements defined in this 
document. These requirements are specified in terms of performance, integrity, and availability 
requirements allocated to each part of the system or environment and avoid the specification of 
requirements in terms of operational uses or specific implementations of ground/space systems. 
This approach provides flexibility in the design of ground ATS facilities and in authorizing the use 
of the ATS applications and data link for different purposes without the need to revise this 
document or the airworthiness approval. Instead, safety and interoperability requirements provide 
information to determine the level necessary to substantiate different uses of ATS applications 
and the data link within the defined operational environment as part of the operational 
authorization. 

In general, any portion of the FANS 1 environments may be changed as long as the new 
environment continues to meet the requirements of this document. Each change should be 
preceded by a safety and interoperability assessment of the change to show that the modification 
(e.g., a new ATS workstation) will continue to meet the requirements of this document. Likewise, 
a safety and interoperability assessment should be conducted prior to implementing a new 
procedure (e.g., reduction in separation minima). 

It is expected that the industry will continue to update standards documents for ADS, ATC DL, and 
AFN functions, and the supporting ARINC 622 ACARS Convergence Process. (The CAAs may 
choose to implement these new capabilities to support future FANS 1 equipped aircraft, however 
future equipage is outside of the scope of this document.) Since the FANS 1 avionics 
implementation is based on specific versions of industry documents (and provisions in this 
document), it is essential to ensure interoperability that the ground software implementation of 
FANS 1 continue to support the functionality defined herein. 

Continued monitoring of changes to both airborne and ground systems is necessary to ensure 
interoperability of FANS 1 applications for a sufficient period to maintain economic viability of both. 
Future changes should take account of moves towards the recommendations of the ICAO ADSP. 
Where possible, updated systems should exhibit enhanced capability without detriment to existing 
support and operational benefit. 

After FANS 1 Part 25 approval any changes in functionality which cause differences from the set 
of industry documents should be specified in the affected document and in the application or 
function message set by an increment in version number. This way, the version number serves 
as an indicator for the functionality being described for future implementations. 

9.2.1 CHANGES TO THE AIRCRAFT ENVIRONMENT 

Changes to the aircraft environment may impact the Safety/Failure Analysis conducted for the 
FANS 1 equipment particularly if the changes affect the system architecture. Changes must be 
approved accordingly. 

The 757/767 (Pegasus ‘00) FANS 1 implementation isolates the hazards to the ATS applications, 
which are resident in the FMCS. The FMCS protects against anomalous behavior that is 
considered to have major effects on the aircraft. 
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The ACARS and other data link components have been shown not to contribute to major failure 
conditions because of system architecture. 

Modifications to the FMCS ATS applications must be approved by the FAA or its delegate. 

Modifications to the airborne datalink components (ACARS, VHF, SATCOM) must be approved 
by a certification authority. The approval must show that the datalink continues to meet the 
requirements of this document and satisfies the Aircraft Equipment Interoperability Test (AEIT) 
contained in Boeing Document D6-36412 or equivalent certification interoperability tests. 

9.2.2 CHANGES TO OTHER ENVIRONMENTS 

Changes to the satellite environment will be validated using the satellite service provider’s 
commissioning test. This test will address the airborne and ground interfaces. 

Changes to the datalink portion of the ground environment will be validated by the datalink service 
provider. 

Changes to the ATS application portion of the ground environment will be validated by the aviation 
authority responsible for that workstation. 

9.3 PROVISIONS FOR IN-SERVICE PROBLEM REPORTING 

To assure that significant problems associated with the airborne equipment can be identified and 
corrected in future avionics updates it is required that in-service problems associated with the 
delivery of ATS messages to/from any FANS 1 airplanes be reported promptly. It is 
recommended that the procedures and forms as specified in Part C of the South Pacific 
Operations Manual be used when reporting problems. 

The airlines should report any in-service problems associated with ATS Data Link via the 
established means for reporting problems directly to their local Boeing Field Service 
Representative. 
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APPENDIX A- 


FANS 1 FMC ATC DL MESSAGE IMPLEMENTATION 


A.1 UPLINK MESSAGE ELEMENT TABLE 

The Uplink Message table is divided by message type. The columns in the tables are defined 
below. 

Uplink Message Element # (UL#): The FMC uses the uplink message element number to 
determine the proper decoding for the variable data contained in the uplink message. The FMC 
also uses the uplink message element number to determine the rule for displaying the uplink 
message element text and variable data, as appropriate, on the CDU. 

Message Element Text: The second column shows the text, with the selected data inserted 
appropriately, which is displayed on the XXXXz ATC UPLINK page on the CDU. 

Associated Downlink Message Element # (DL#): This column is for commentary only. For 
clearances and expect clearances, the downlink message element(s) identified is the request for 
which a flight crew would operationally be expecting the uplink message element. For requests 
and confirms, the downlink message element(s) identified is the report the flight crew would 
operationally be expected to send. 'Mult' indicates that multiple downlink message elements 
could be related to the indicated uplink message element. N/A indicates that there is neither a 
defined data link request for the uplink element nor is there a defined report which the crew 
should send in response to the uplink. 

Display and Loading Provisions (D,P,L): Full text and variable data display is provided for 
those message elements marked 'D'. Capability is provided for the flight crew to load some or all 
of the variable data contained in those message elements marked 'L'. Limited display capability, 
and full text and variable data print capability are provided, for those message elements marked 
'P'. 


Additional Information: This column provides additional information regarding message usage, 
display format, and data defaults. 



Responses/Acknowledgments 


EBB 

Additional Information 

0 

UNABLE 


D 


T 

STANDBY 


D 


2 

REQUEST DEFERRED 


D 


m 

ROGER 


D 


4 

AFFIRM 


D 


5 

NEGATIVE 


D 



Rev: B 


D926T0280 


78 























Vertical Clearances 



Additional Information | 


EXPECT [altitudel 





EXPECT CLIMB AT [timel 

52 



|8_ 

EXPECT CLIMB AT [position! 

52 



0B 

EXPECT DESCENT AT [time] 




tm 

EXPECT DESCENT AT [position] 




m 

EXPECT CRUISE CLIMB AT [timel 




e m 

EXPECT CRUISE CLIMB AT [position] 




EES 

AT [time] EXPECT CLIMB TO [altitude] 




EEH 

AT [position] EXPECT CLIMB TO [altitudel 




sm 

AT [time] EXPECT DESCENT TO [altitudel 




«■'» 

AT [position] EXPECT DESCENT TO [altitudel 




um 

AT [time] EXPECT CRUISE CLIMB TO [altitude] 

54 



am 

AT [position] EXPECT CRUISE CLIMB TO [altitudel 

54 



im 

MAINTAIN [altitudel 




M 

CLIMB TO AND MAINTAIN [altitudel 

9 




AT [time] CLIMB TO AND MAINTAIN [altitude] 

13 




AT [position] CLIMB TO AND MAINTAIN [altitudel 

11 




DESCEND TO AND MAINTAIN [altitude] 

10 



a 

AT [timel DESCEND TO AND MAINTAIN [altitude] 

14 



■ 

AT [position] DESCEND TO AND MAINTAIN 
[altitudel 

12 

D 



CLIMB TO REACH [altitude] BY [time] 

9 




CLIMB TO REACH [altitudel BY [position] 

9 



iSe! 

DESCEND TO REACH [altitude] BY [time] 

10 



a 

DESCEND TO REACH [altitude] BY [position] 

10 



EM 

MAINTAIN BLOCK [altitude] TO [altitude] 

7 



II 

CLIMB TO AND MAINTAIN BLOCK [altitude] TO 
[altitude] 

7 

D 



DESCEND TO AND MAINTAIN BLOCK [altitude] 

TO [altitude] 

7 

D 



CRUISE [altitudel 




3M 

CRUISE CLIMB TO [altitude] 

_ 




CRUISE CLIMB ABOVE [altitudel 





EXPEDITE CLIMB TO [altitude] 




EM 

EXPEDITE DESCENT TO [altitudel 




EH 

IMMEDIATELY CLIMB TO [altitudel 




EM 

IMMEDIATELY DESCEND TO [altitudel 


IsHHI 


EM 

IMMEDIATELY STOP CLIMB AT [altitude] 




eh 

IMMEDIATELY STOP DESCENT AT [altitudel 




EHI 

CLIMB AT [verticalRate] MINIMUM 




rea 

CLIMB AT [verticalRatel MAXIMUM 




rea 

DESCEND AT [verticalRate] MINIMUM 




EE1 

DESCEND AT [verticalRatel MAXIMUM 


EBSI 
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Crossing Constraints 



Additional Information | 


EXPECT TO CROSS [positionl AT [altitudel 




a 

EXPECT TO CROSS [position] AT OR ABOVE 
[altitudel 

N/A 

D 


a 

EXPECT TO CROSS [position] AT OR BELOW 
[altitudel 

N/A 

D 


a 

EXPECT TO CROSS [position] AT AND MAINTAIN 
[altitudel 

N/A 

D 


vm 

CROSS [position] AT [altitude] 




EM 

CROSS [positionl AT OR ABOVE [altitudel 




2* 

CROSS [position] AT OR BELOW [altitude] 




EM 

CROSS [positionl AT AND MAINTAIN [altitude] 





CROSS [position] BETWEEN [altitude] AND 
[altitudel 

N/A 

D 



CROSS [positionl AT [time[ 





CROSS [positionl AT OR BEFORE [time[ 




EM 

CROSS [position] AT OR AFTER [time] 




im 

CROSS [positionl BETWEEN [time] AND [timel 





CROSS [position] AT [speed] 




wm 

CROSS [positionl AT OR LESS THAN [speedl 




mm 

CROSS [position] AT OR GREATER THAN [speed] 




es 

CROSS [positionl AT [timel AT [altitudel 





CROSS [position] AT OR BEFORE [time] AT 
[altitudel 

N/A 

D 



CROSS [position] AT OR AFTER [time] AT 
[altitudel 

N/A 

D 



CROSS [position] AT AND MAINTAIN [altitude] AT 
[speedl 

N/A 

D 



AT [time] CROSS [position] AT AND MAINTAIN 
[altitudel 

N/A 

D 



AT [time] CROSS [position] AT AND MAINTAIN 
[altitudel AT [speedl 

N/A 

D 




Lateral Offsets 



Additional Information | 


OFFSET [direction] [distanceOffsetl 

15 




AT [position] OFFSET [direction] [distanceOffset] 

16 



EM 

AT [timel OFFSET [direction] [distanceOffsetl 

17 



tm 

PROCEED BACK ON ROUTE 




im 

REJOIN ROUTE BY [positionl 




HB 

REJOIN ROUTE BY [time] 




mm 

EXPECT BACK ON ROUTE BY [positionl 

51 



am 

EXPECT BACK ON ROUTE BY [time] 

51 



sm 

RESUME OWN NAVIGATION 
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Route Modifications 


PREDEPARTURE CLEARANCE 



PROCEED DIRECT TO [position] 


WHEN ABLE PROCEED DIRECT TO [position] 


AT [time] PROCEED DIRECT TO [position]_ 


AT [position] PROCEED DIRECT TO [position] 


AT [altitude] PROCEED DIRECT TO [position] 


CLEARED TO [position] VIA ROUTE CLEARANCE 


CLEARED ROUTE CLEARANCE 


CLEARED [procedureName] 


CLEARED TO DEVIATE UP TO [direction] 
[distanceOffset] 


AT [position] CLEARED ROUTE CLEARANCE 


AT [position] CLEARED [procedureName] 


EXPECT ROUTE CLEARANCE 


AT [position] EXPECT ROUTE CLEARANCE 


EXPECT DIRECT TO [position] 


AT [position] EXPECT DIRECT TO [position] 


AT [time] EXPECT DIRECT TO [position]_ 


AT [altitude] EXPECT DIRECT TO [position] 


HOLD AT [position] MAINTAIN [altitude] INBOUND N/A 
TRACK [degrees]/[direction] TURN LEGTIME 
[legType]_ 


HOLD AT [position] AS PUBLISHED MAINTAIN 
[altitude]_ 


EXPECT FURTHER CLEARANCE AT [time] 


TURN [direction] HEADING [degrees] 


TURN [direction] GROUND TRACK [degrees] 


FLY PRESENT HEADING 


AT [position] FLY HEADING [degrees] 


IMMEDIATELY TURN [direction] HEADING 
[degrees] 


EXPECT [procedureName] 


Message not supported, no display on XXXX ATC 
UPLINK page 


IISqi 

g§gMTi» 

llJHthii 



mum] 






Additional Information 


Print to see full text of [predepartureClearance]. 


Print to see full text of [routeclearance]. 


Print to see full text of [routeclearance[. 


Print to see full text of [routeclearance]. 


Print to see full text of [routeclearance[. 


Print to see full text of [routeclearance]. 


LEGTIME" or "LEGDIST" displayed depending on 
[legType], 



mil 

EDI 


ma 


Speed Changes 


Additional Information 

AT [timel EXPECT [speedl 



AT [position] EXPECT [speed] 



AT [altitudel EXPECT [speedl 



AT [time] EXPECT [speed] TO [speed] 

50 D 

Note: DL#50 is not supported in this software version 

AT [position] EXPECT [speedl TO [speedl 

50 D 

Note: DL#50 is not supported in this software version 

AT [altitude] EXPECT [speed] TO [speed] 

50 D 

Note: DL#50 is not supported in this software version 

MAINTAIN [speed] 

IDSUBHH 


MAINTAIN PRESENT SPEED 



MAINTAIN [speedl OR GREATER 



MAINTAIN [speed] OR LESS 




MAINTAIN [speedl TO [speedl 

19 

D 

Note: DL#19 is not supported in this software version 

INCREASE SPEED TO [speed] 

18 

E^M 


INCREASE SPEED TO [speedl OR GREATER 

18 



REDUCE SPEED TO [speedl 

18 



REDUCE SPEED TO [speedl OR LESS 

18 

EHHI 


DO NOT EXCEED [speed] 




RESUME NORMAL SPEED 

BUM 

E^HH 
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Contact/Monitor/Surveillance Requests 


CONTACT [icaollnitName] ON [frequency] 


AT [position] CONTACT [icaollnitName] ON 
[frequency] 


AT [time] CONTACT [icaollnitName] ON 
[frequency] 


MONITOR [icaollnitName] ON [frequency] 


AT [position] MONITOR [icaollnitName] ON 
[frequency] 


AT [time] MONITOR [icaollnitName] ON 
[frequency] 


SQUAWK [beaconCode]_ 


STOP SQUAWK 


SQUAWK ALTITUDE 


STOP ALTITUDE SQUAWK 


SQUAWK IDENT 


Additonal Information 












fEfll 

eeh 

tEEl 

Ed 

ma 


sn 

EE3 


Report/Confirmation Requests 


REPORT BACK ON ROUTE 


REPORT LEAVING [altitude] 


REPORT LEVEL [altitude] 


REPORT PASSING [position] 


REPORT REMAINING FUEL AND SOULS ON 
BOARD 


CONFIRM POSITION 


CONFIRM ALTITUDE 


CONFIRM SPEED 


CONFIRM ASSIGNED ALTITUDE 


CONFIRM ASSIGNED SPEED 


CONFIRM ASSIGNED ROUTE 


CONFIRM TIME OVER REPORTED WAYPOINT 


CONFIRM REPORTED WAYPOINT 


CONFIRM NEXT WAYPOINT 


CONFIRM NEXT WAYPOINT ETA 


CONFIRM ENSUING WAYPOINT 


CONFIRM REQUEST 


CONFIRM SQUAWK 


CONFIRM HEADING 


CONFIRM GROUND TRACK 


REQUEST POSITION REPORT 48 


REPORT REACHING [altitude] 


REPORT REACHING BLOCK [altitude] TO 
[altitude] 


REPORT DISTANCE [tofrom]]position1_ 


CONFIRM ATIS CODE 


Additional Information 



DL #’s 29 or 30 may also be sent as specified in table 4 


DL # 80 may also be sent as specified in table 4 


DL # 80 may also be sent as specified in table 4 


DL # 80 may also be sent as specified in table 4 


DL #'s 29, 30or 80 may also be sent as specified in 
table 4 


"TO" or "FROM" displayed depending on [toFrom] value. 



Negotiation Requests 



Additional Information 

KH 

WHEN CAN YOU ACCEPT [altitude] 

67b, 

67e 

D 


fEEl 

CAN YOU ACCEPT [altitude] AT [position] 

OKI 




CAN YOU ACCEPT faltitudel AT ]time] 





WHEN CAN YOU ACCEPT [speed] 

EnH! 

D 



WHEN CAN YOU ACCEPT [direction] 
[distanceOffsetl OFFSET 

67d,67 

9 

D 
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Air Traffic Advisories 



Additional Information | 


ALTIMETER [altimeterl 





RADAR SERVICES TERMINATED 





RADAR CONTACT [positionl 





RADAR CONTACT LOST 





CHECK STUCK MICROPHONE [frequency 




E15E1 

ATIS [atisCode] 

UUiHU 





System Management Messages 


mail 

Additional Information | 


DOWNLINK ERROR 





system message (NEXT DATA AUTHORITY), no 
display on XXXXz ATC UPLINK page 

N/A 


[icaoUnitName] displayed on ATC LOGON/STATUS 
page as 'NEXT CTR'. 


system message (END SERVICE), no display on 
XXXXz ATC UPLINK page 

N/A 


Upon receipt, FMC will discontinue communication with 
ACT CTR and NEXT CTR becomes new ACT CTR. 


SERVICE UNAVAILABLE 





system message ([icaoUnitName] [tp4Table]), no 
display on XXXXz ATC UPLINK page 

73 


[icaoUnitName] displayed on ATC LOGON/STATUS 
page as 'ACT CTR'. 



Additional Messages 



Additional Information | 


WHEN READY 


[•KS 



THEN 





DUE TO TRAFFIC 

mm 




DUE TO AIRSPACE RESTRICTION 





DISREGARD 





[freetextl 

mm. 




[freetextl 

[SSH 




MAINTAIN OWN SEPARATION AND VMC 

mm 



EH! 

AT PILOTS DISCRETION 

I3I!IIH 
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A.2 [POSITION] AND [ROUTECLEARANCE] VARIABLE LOADING 

a. [position] LOADING 

The following rules for [position] loading apply to standalone [position] variables, as in message element 77, and to those embedded in the 
[routeclearance] variable. 

In the message structure defined in DO-219, the [position] variable is defined as a choice of ‘fixname’, ‘navaid’, ‘airport’, ‘latitudeLongitude’, or 
‘placebearingdistance’. The first three choices have "overlapping" definitions. [Fixname] is an IA5String (Size(1..5)); [navaid] is an IA5String 
(Size(1..4)); and [airport] is an IA5String (Size(4)). Consequently, a 1, 2, or 3 character identifier could be encoded as a [fixname] or [navaid], and a 
four character identifier could be encoded as any of the first three [position] choices. 

The FMC NDB is configured to the ARINC 424 specification, which defines the record structure and naming conventions for NDB data. When the 
FMC receives an uplink with a loadable message element containing the [position] variable, it uses the [position] choice to determine which of its 
NDB records to search for a matching identifier. This is required in order for the FMC to be able to load the uplinked [position] into the flight plan. 

For example, if an uplink with a [position] choice of 'navaid' is received, the FMC will search only the NDB Navaid record for a matching identifier. 
Similarly, the ‘airport’ choice leads to a search of the NDB airport record and the ‘fixname’ choice leads to a search of the NDB waypoint record and 
the NDB non-directional beacon record (explained further below). 

If a match is not found, then the FMC will not load the specified [position] into the flight plan. Limiting the search in this manner (i.e., as opposed to 
searching all NDB records, irrespective of the [position] choice) decreases, but does not eliminate, the likelihood of the FMC finding duplicate 
matching identifiers. 

There are also many non-directional beacons which have the same names as the VHF navaids to which they lie close. ARINC 424 allows an 
implementor the option of modifying the names of the non-directional beacons (by adding an NB) suffix and adding the entries to the waypoint 
record; or creating a separate non-directional beacon record. The FMC NDB has a separate record for non-directional beacons. Since there is no 
DO-219 [position] choice for non-directional beacons, a Non-directional Beacon included in a loadable [position] variable has to be defined with a 
choice of ‘fixname’, in order for the FMC to look for a match in its Non-directional Beacon record for a matching identifier. 

The FMC will create a waypoint at the specified [position] when the ‘latitudeLongitude’ choice is selected. 

If the ‘placebearingdistance’ choice is selected, the [fixname] must match an identifier in the FMC Navigation Database (waypoint, navaid, airport, 
or non-directional beacon), otherwise, the [fixname] and the corresponding [placebearingdistance] are not loadable. 

Any [placebearingdistance] with a [distance] choice of 1 (distancekm) is not loadable. 

Any [distancenm] greater than 700nm is not loadable. 
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b. [routeclearance] LOADING 

The FMC has the capability to store 2 routes, designated as route 1 and route 2. The route which defines the flight plan along which the 
airplane is to be flown is the active route. For elements 73 and 80, the "selected route" is the active route, if one exists, else the empty 
route, if one route is empty, else, route 1. For elements 79 and 83, the selected route is the active route. 

When loaded, elements 73 and 80 replace the entire existing route, unless the uplinked route does not include an [airportdeparture] and/or an 
[airportdestination]. If either of these is absent in the uplink, then the FMC will retain the departure or destination airport, as appropriate, from the existing 
route. 

When loaded, elements 79 and 83 modify, but do not replace, the existing route. 


Variable Name 

Loaded into the selected 
flight plan as: 

Additional information 

[airportdeparture] 

origin airport for the selected 
route 

The [airportdeparture] variable is not loadable if the [airport] identifier does not 
match an identifier in the FMC Navigation Database. 

Otherwise, the [airportdeparture] is loadable. 

[airportdestination] 

destination airport for the 
selected route 

The [airportdestination] variable is not loadable if the [airport] identifier does not 
match an identifier in the FMC Navigation Database. 

Otherwise, the [airportdestination] is loadable. 

[runwaydeparture] 

[runway] 

[runwaydirection] 

[runwayconfiguration] 

departure runway direction 
and configuration for the 
selected route 

The [runwaydeparture] variable is not loadable if the [runway] [runwaydirection] 
and [runwayconfiguration] do not match a runway identifier for the applicable origin 
airport in the FMC Navigation Database. 

Otherwise, the [runwaydeparture] is loadable. 

[proceduredeparture] 

[procedurename] 

[procedure] 

[proceduretransition] 

departure procedure and 
departure transition for the 
selected route 

The [proceduredeparture] variable is not loadable if the [proceduretype] choice is 0 
(arrival) or 1 (approach). 

The [proceduredeparture] is not loadable if the [procedure], or [procedure] and 
[proceduretransition], do not match a departure procedure identifier, or departure 
procedure and transition identifiers, for the applicable origin airport in the FMC 
Navigation Database. 

Otherwise, the [proceduredeparture] is loadable. 

[runwayarrival] 

[runway] 

[runwaydirection] 

[runwayconfiguration] 

arrival runway direction and 
configuration for the selected 
route 

The [runwayarrival] variable is not loadable if the [runway] [runwaydirection] and 
[runwayconfiguration] do not match a runway identifier for the applicable 
destination airport in the FMC Navigation Database. 

Otherwise, the [runwayarrival] is loadable 
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Variable Name 

Loaded into the selected 
flight plan as: 

Additional information 

[procedureapproach] 

[procedurename] 

[procedure] 

[proceduretransition] 

approach procedure and 
approach transition for the 
selected route 

The [procedureapproach] variable is not loadable if the [proceduretype] choice is 0 
(arrival) or 2 (departure). 

The [procedureapproach] is not loadable if the [procedure], or [procedure] and 
[proceduretransition], do not match an approach procedure identifier, or approach 
procedure and transition identifiers, for the applicable destination airport in the 

FMC Navigation Database. 

Approach procedures with eight-character identifiers (e.g., ILS2 24L) are loadable 
provided that the approach type and multiple approach character code (e.g., ILS2) 
are encoded as the [procedureapproach] variable and the runway number and 
direction (e.g., 24L) are encoded into the [runwayarrival] variable. Note that 
breaking the procedure identifier in this manner is necessary, as the DO-219 
[procedurename] variable has a maximum size of 6 characters. 

Otherwise, the [procedureapproach] is loadable 

[procedurearrival] 

[procedurename] 

[procedure] 

[proceduretransition] 

arrival procedure and arrival 
transition for the selected 
route 

The [procedurearrival] variable is not loadable if the [proceduretype] choice is 1 
(approach) or 2 (departure). 

The [procedurearrival] is not loadable if the [procedure], or [procedure] and 
[proceduretransition], do not match an arrival procedure identifier, or arrival 
procedure and transition identifiers, for the applicable destination airport in the 

FMC Navigation Database. 

Otherwise, the [procedurearrival] is loadable 

[airway intercept] 

the first airway in the en route 
portion of the selected route; 
the FMC automatically 
selects the point at which the 
airplane should join the 
airway. 

Any [airwayintercept] variable which does not match an airway identifier in the 

FMC Navigation Database is not loadable. 

Any [airwayintercept] for which the point at which the airplane is to leave the 
airway is not defined by a [publishedidentifier] encoded as the first item in the 
[routeinformation] is not loadable. 

Otherwise, the [airwayintercept] is loadable. 
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Variable Name 

Loaded into the selected 
flight plan as: 

Additional information 

[routeinformation] 

[publishedidentifier] 

[latitudelongitude] 

[placebearingplacebearing] 

[placebearingdistance] 

[airwayidentifier] 

[trackdetail] 

en route data for the selected 
route 

The FMC ignores (and does not attempt to load) any [trackdetail] encoded in the 
[routeinformation] portion of a [routeclearance] variable. 

Any [publishedidentifier] [fixname], [placebearingdistance] [fixname] or 
[placebearingplacebearing] [fixname], for which the [fixname] does not match an 
identifier in the FMC Navigation Database (waypoint, navaid, airport, or non- 
directional beacon), is not loadable. In addition, the [publishedidentifier][fixname] 
can be a runway identifier and is loadable if the runway identifier is appropriate for 
the arrival airport. 

Any [airwayidentifier] which does not match an airway identifier in the FMC 
Navigation Database is not loadable. 

Any [airwayidentifier] for which the point at which the airplane is to join the airway 
is not defined by a [publishedidentifier] or by another [airwayidentifier] immediately 
preceding the [airwayidentifier] in the [routeinformation] is not loadable. 

Any [airwayidentifier] for which the point at which the airplane is to leave the airway 
is not defined by a [publishedidentifier] or by another [airwayidentifier] immediately 
following the [airwayidentifier] in the [routeinformation] is not loadable. 

Any [placebearingdistance] with a [distance] choice of 1 (distancekm) is not 
loadable. 

Any [distancenm] greater than 700nm is not loadable. 

The FMC attempts to load all other [routeinformation] variables into the selected 
route in the order in which they occur in the [routeinformation] variable. 
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Variable Name 


[routeinformationadditional] 

[routeinformationadditional] 

[atwalongtrackwaypoint- 

sequence] 

[atwalongtrackwaypoint] 

[routeinformationadditional] 

[atwalongtrackwaypoint] 

[position] 


[routeinformationadditional] 

[atwalongtrackwaypoint] 

[aTWdistance] 

[aTWdistancetolerance] 

[distance] 


[routeinformationadditional] 

[atwalongtrackwaypoint] 

[speed] 


Loaded into the selected Additional information 
flight plan as: 


place-bearing-distance (PBD) When the [aTWalongtrackwaypoint] [position], [aTWdistance], and 
waypoint [aTWdistancetolerance] are all loadable (see below), the FMC converts these to a 

PBD and then inserts the resulting PBD into the correct location in the selected 
route 

If the [position] does not match any of the following: 

a) a loadable [publishedidentifier] or [placebearingdistance] in the uplinked 
[routeinformation], 

b) a waypoint on an airway defined by an [airwayidentifier] in the uplinked 
[routeinformation], 

c) a fix in a [proceduredeparture], [procedurearrival], or [procedureapproach] 
included in the uplinked [routeclearance] 

d) the [position] portion of element 79 or 83, 

then the [position] (and the [aTWalongtrackwaypoint]) is not loadable. 

Otherwise, the [position] is loadable and is used to convert the along track 
waypoint to a PBD, as stated above. 

If the [aTWdistance] [distance] choice is 1 (distancekm), then the [aTWdistance] 
(and the [aTWalongtrackwaypoint]) is not loadable. 

If the resulting ATW would not fall between the [position] and the preceding or 
following waypoint or if the [distancenm] is greater than 700nm, then the 
[aTWdistance] (and the [aTWalongtrackwaypoint]) is not loadable. 

Otherwise the [distance] is loadable, and the [distance] and 
[aTWdistancetolerance] are used to covert the along track waypoint to a PBD, as 
stated above. 

speed constraint for the If the speed choice is anything other than choice 0 (speedindicated) or if the 

corresponding along track [speedindicated] value is less than 10 (lOOkts), then the [speed] is not loadable, 

waypoint (PBD) If there is no [aTWaltitude] defined for the corresponding [aTWalongtrackwaypoint] 

or the [aTWaltitude][altitude] is not loadable (see below), then the [speed] is not 
loadable. 

Otherwise, the [speed] is loadable. 
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Variable Name 

Loaded into the selected 
flight plan as: 

Additional information 

[routeinformationadditional] 

[aTWalongtrackwaypoint- 

sequence] 

[aTWaltitudesequence] 

[aTWaltitude] 

[aTWaltitudetolerance] 

[altitude] 

AT, AT OR ABOVE or AT OR 
BELOW altitude constraint or 
window altitude constraint for 
the corresponding along track 
waypoint (PBD) 

If the [altitude] choice for either altitude in the [aTWaltitudesequence] is anything 
other than choice 0 (altitudeqnh), 1 (altitudeqnhmeters), or 6 (altitudeflightlevel), 
then the [aTWaltitude] [altitude] is not loadable. 

If the value for a single [aTWaltitude] or the first [altitude] in the 
[aTWaltitudeseqence] is at or above the current cruise altitude, then that 
[aTWaltitude] [altitude] is not loadable. 

Otherwise the [aTWaltitude] [altitude] and [altitudetolerance] are loadable. 

[routeinformationadditional] 

[reportingpoints] 

[latlonreportingpoints] 

[latitudereportingpoints] 

[latitudedirection] 

[Iatitudedegrees] 

[longitudereportingpoints] 

[longitudedirection] 

[longitudedegrees] 

[degreeincrement] 

latitude/longitude waypoint or 
series of latitude/longitude 
waypoints 

If a latitude defined by a [latitudedirection] and [Iatitudedegrees], or a longitude 
defined by a [longitudedirection] and [longitudedegrees], does not intersect the 
selected route, then the [latlonreportingpoints] is not loadable. If a latitude defined 
by a [latitudedirection] and [Iatitudedegrees], or a longitude defined by a 
[longitudedirection] and [longitudedegrees], does intersect the selected route, then 
the FMC will insert a latitude/longitude waypoint at the intersection point. 

If the [degreeincrement] is included, then the FMC will insert reporting points at 
intervals along the selected route, as defined by the [degreesincrement] along the 
direction of flight starting at the intersection point. 

[routeinformationadditional] 

[interceptcoursefromsequence] 

[interceptcoursefrom] 

intercept course from 
waypoint 

When the [interceptcoursefrom] [interceptcoursefromselection] and [degrees] are 
both loadable (see below), the FMC inserts the intercept course from waypoint 
into the correct location in the selected route 

If, after loading, the pilot does not terminate the intercept course from leg, then it 
remains an intercept course from leg in the flight plan. 

If, after loading, the pilot does terminate the intercept course from leg, then the 

FMC creates a latitude longitude waypoint at the termination point and the 
intercept course from leg no longer exists. 
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Variable Name 

Loaded into the selected 
flight plan as: 

Additional information 

[routeinformationadditional] 

[interceptcoursefromsequence] 


If the [interceptcoursefromselection] does not match any of the following: 

[interceptcoursefrom] 


a) a loadable [publishedidentifier], [latitudelongitude], 

[interceptcoursefromselect- 


[placebearingplacebearing], or [placebearingdistance] in the uplinked 

ion] 


[routeinformation], 

b) a waypoint on an airway defined by an [airwayidentifier] in the uplinked 
[routeinformation], 

c) a fix in a [proceduredeparture], [procedurearrival], or [procedureapproach] 
included in the uplinked [routeclearance] 

d) the [position] portion of element 79 or 83, 

then the [interceptcoursefromselection] (and the [interceptcoursefrom]) is not 
loadable. 

Otherwise, the [interceptcoursefromselection] is loadable. 

[routeinformationadditional] 

[interceptcoursefromsequence] 

[interceptcoursefrom] 

[degrees] 


[degrees] is loadable, irrespective of the [degrees] choice 
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Variable Name 

Loaded into the selected 
flight plan as: 

Additional information 

[routeinformationadditional] 

[holdatwaypointsequence] 

[holdatwaypoint] 

Hold position and associated 
data for a given holding 
pattern in the selected route 

If the [position] is loadable (see below), the [holdatwaypoint] is loadable regardless 
of whether any of the associated data exist or are not loadable. The FMC has pre¬ 
defined defaults for the associated data. 

[routeinformationadditional] 

[holdatwaypoint] 

[position] 

position for a given hold in 
the selected route 

If the [position] does not match any of the following: 

a) a loadable [publishedidentifier], [latitudelongitude], or [placebearingdistance] 
in the uplinked [routeinformation], 

b) a waypoint on an airway defined by an [airwayidentifier] in the uplinked 
[routeinformation], 

c) a fix in a [proceduredeparture], [procedurearrival], or [procedureapproach] 
included in the uplinked [routeclearance] 



d) the [position] portion of element 79 or 83, 



then the [position] (and the [holdatwaypoint]) is not loadable. 



Otherwise, the [position] is loadable. 

[routeinformationadditional] 

[holdatwaypoint] 

[holdatwaypointspeedlow] 

speed constraint associated 
with a given hold in the 
selected route 

If both the [holdatwaypointspeedlow] and [holdatwaypointspeedhigh] variables are 
specified, then the FMC ignores (and does not attempt to load) either speed. 

If the [holdatwaypointspeedlow] [speed] choice is anything other than choice 0 
(speedindicated) or if the [speed] value is less than 10 (1 OOkts), then the 
[holdatwaypointspeedlow] is not loadable. 

If there is no [aTWaltitude] defined for the corresponding [holdatwaypoint] 

[position] or the [aTWaltitude][altitude] is not loadable (see below), then the 
[holdatwaypointspeedlow] is not loadable. 

Otherwise, the [holdatwaypointspeedlow] is loadable. 

[routeinformationadditional] 

[holdatwaypoint] 

[aTWaltitude] 

[aTWaltitudetolerance] 

[altitude] 

AT, AT OR ABOVE or AT OR 
BELOW altitude constraint 
associated with a given hold 
in the selected route 

If the [altitude] choice is anything other than choice 0 (altitudeqnh), 1 
(altitudeqnhmeters), or 6 (altitudeflightlevel), then the [aTWaltitude] [altitude] is not 
loadable. 

If the value for the [aTWaltitude] is above the current cruise altitude, then that 
[aTWaltitude] [altitude] is not loadable. 

Otherwise the [aTWaltitude] [altitude] and [altitudetolerance] are loadable. 
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Variable Name 

Loaded into the selected 
flight plan as: 

Additional information 

[routeinformationadditional] 

[holdatwaypoint] 

[holdatwaypointspeedhigh] 

speed constraint associated 
with a given hold in the 
selected route 

If both the [holdatwaypointspeedlow] and [holdatwaypointspeedhigh] variables are 
specified, then the FMC ignores (and does not attempt to load) either speed. 

If the [holdatwaypointspeedhigh] [speed] choice is anything other than choice 0 
(speedindicated), or if the [speed] value is less than 10 (100 kts), then the 
[holdatwaypointspeedhigh] is not loadable. 

If there is no [aTWaltitude] defined for the corresponding [holdatwaypoint] 

[position] or the [aTWaltitude][altitude] is not loadable (see above), then the 
[holdatwaypointspeedhigh] is not loadable. 

Otherwise, the [holdatwaypointspeedhigh] is loadable. 

[routeinformationadditional] 

[holdatwaypoint] 

[direction] 

Turn direction associated 
with a given hold in the 
selected route 

If the [direction] choice is anything other than choice 0 (left) or 1 (right), then the 
[direction] is not loadable. 

Otherwise, the [direction] is loadable. 

[routeinformationadditional] 

[holdatwaypoint] 

[degrees] 

Inbound course associated 
with a given hold in the 
selected route 


[routeinformationadditional] 

[holdatwaypoint] 

[EFCtime] 

Expect Further Clearance 

Time associated with a given 
hold in the selected route 


[routeinformationadditional] 

[holdatwaypoint] 

[legtype] 

Leg Distance, if specified for 
a given hold in the selected 
route. 

Otherwise, Leg Time 
associated with a given hold 
in the selected route 

When the [legtype] is [legdistance] and the [legdistance] choice is 1 
(legdistancemetric) then the [legdistance] is not loadable. 

Otherwise, the [legtype] is loadable. 
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Variable Name 

Loaded into the selected 
flight plan as: 

[routeinformationadditional] 

[waypointspeedaltitude] 

speed, altitude, and 
associated position for a 
given waypoint speed and 
altitude or altitude-only 
constraint in the selected 
route 

[routeinformationadditional] 

[waypointspeedaltitude] 

[position] 

position of a waypoint in the 
selected route which has a 
corresponding speed and 
altitude or altitude-only 
constraint 

[routeinformationadditional] 

[waypointspeedaltitude] 

[speed] 

speed portion of speed and 
altitude constraint for a 
waypoint in the selected 
route 

[routeinformationadditional] 

[waypointspeedaltitude] 

[ATWaltitudesequence] 

AT, AT OR ABOVE, or AT 

OR BELOW altitude 
constraint or window altitude 
constraint for the 
corresponding 
[waypointspeedaltitude] 
[position] 
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Additional information 


If the [position] does not match any of the following: 

a) a loadable [publishedidentifier], [latitudelongitude], or [placebearingdistance] 
in the uplinked [routeinformation], 

b) a waypoint on an airway defined by an [airwayidentifier] in the uplinked 
[routeinformation], 

c) a fix in a [proceduredeparture], [procedurearrival], or [procedureapproach] 
included in the uplinked [routeclearance] 

d) the [position] portion of element 79 or 83, 

then the [position] (and the [waypointspeedaltitude]) is not loadable. 

Otherwise, the [position] is loadable.. 

If the [speed] choice is anything other than choice 0 (speedindicated)) or if the 
[speed] value is less than 10 (lOOkts), then the [speed] is not loadable. 

If there is no [aTWaltitude] defined for the corresponding [waypointspeedaltitude] 
[position] or the [aTWaltitude][altitude] is not loadable (see below), then the [speed] 
is not loadable. 

Otherwise, the [speed] is loadable. 

If the [altitude] choice for either altitude in the [aTWaltitudesequence] is anything 
other than choice 0 (altitudeqnh), 1 (altitudeqnhmeters), or 6 (altitudeflightlevel), 
then the [aTWaltitude] [altitude] is not loadable. 

If the value for a single [aTWaltitude] or the first [altitude] in the 
[aTWaltitudseqence] is at or above the current cruise altitude, then that 
[aTWaltitude] [altitude] is not loadable. 

Otherwise the [aTWaltitude] [altitude] and [altitudetolerance] are loadable. 
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Variable Name 

Loaded into the selected 
flight plan as: 

Additional information 

[RTArequiredtimeofarrival] 

RTA on the specified 
position in the selected 
route 

When the [RTArequiredtimeofarrival] [position] is loadable (see below), the 

FMC applies the RTA to the specified position in the selected route. 

[RTArequiredtimeofarrival] 

[position] 

position of a waypoint in 
the selected route which 
has an RTA applied to it 

If the [position] does not match: 

a) a loadable [publishedidentifier], [latitudelongitude], or [placebearingdistance] 
in the uplinked [routeinformation], 

b) a waypoint on an airway defined by an [airwayidentifier] in the uplinked 
[routeinformation], 

c) a fix in a [proceduredeparture], [procedurearrival], or [procedureapproach] 
included in the uplinked [routeclearance] 

d) the [position] portion of element 79 or 83, 

then the [position] (and the [RTArequiredtimeofarrival]) is not loadable. 

Otherwise, the [RTArequiredtimeofarrival] is loadable. 

[RTArequiredtimeofarrival] 

[RTAtime]] 

[RTAtime] and 
[timetolerance] for the 
specified [position] 


[RTArequiredtimeofarrival] 

[RTAtolerance] 

NOT USED 



Rev: B 


D926T0280 


94 




















A.3 DOWNLINK MESSAGE ELEMENT TABLE 

The downlink message element table is divided by message type. The columns in the tables are 
defined below. 

Downlink Message Element # (DL#): The FMC selects the appropriate downlink message 
element number based on the response, request or report messages created by the flight crew. 
The FMC sends the downlink message element number and variable data in the downlink. 

Message Element Text: The second column shows the text, with the selected data inserted 
appropriately, which is displayed to the flight crew as verification of the downlink message. 

Associated Uplink Message Element # (UL#): This column is for commentary only. For 
requests, the uplink message element(s) identified is the clearance the crew would operationally 
expect to receive. For reports, the uplink message element(s) identified is the request for which 
the crew would operationally be expected to generate the downlink. 'Mult' indicates that multiple 
uplink message elements could be related to the downlink message element. 'N/A' indicates that 
there is no related clearance or request for report. 

FMC Provisions (P, E, N): Text and default data or selection prompts to solicit data entry or 
message selection are provided for those message elements marked 'P 1 . Text and box or dash 
prompts to solicit data entry are provided for those message elements marked 'E'. No selection 
or entry provisions are provided for those message elements marked 'N'. 

Additional Information: This column provides additional information regarding message usage, 
display format, and data defaults. 



Responses 



Additional Information 

0 

WILCO 

mult 

p 

ACCEPT prompt provided. WILCO is sent if appropriate for 
uplink message. 

1 

UNABLE 

mult 

p 

REJECT prompt provided. UNABLE is sent if appropriate for 
uplink message. 

m 

STANDBY 

GSMHi 

p 

STANDBY prompt provided if appropriate for uplink message. 

m 

ROGER 

mult 

p 

ACCEPT prompt provided. ROGER is sent if appropriate for 
uplink message. 

* 

AFFIRM 

mult 

p 

ACCEPT prompt. AFFIRM is sent if appropriate for uplink 
message. 

m 

NEGATIVE 

mult 

p 

REJECT prompt provided. NEGATIVE is sent if appropriate for 
uplink message. 
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Vertical Requests 



Additional Information 


REQUEST [altitude! 

19 

E 

Selected when alt. entry within +/-150' of current alt. 

■ 

REQUEST BLOCK [altitude] TO [altitude] 

30, 31, 
32 

E 

Selected when xxxxx/xxxxx entered in ALTITUDE request field. 

8 

REQUEST CRUISE CLIMB TO [altitude] 

34 

m 

Selected when alt. entry > 150' above current alt. and CRZ CLB 
prompt selected. 

U 

REQUEST CLIMB TO [altitude] 

20, 26, 
27 

E 

Select when alt. entry > 150' above current alt. 

10 

REQUEST DESCENT TO [altitude] 

23, 28, 
29 

E 

Selected when alt. entry > 150' below current alt. 

11 

AT [position] REQUEST CLIMB TO [altitude] 

22 

E 

Selected when alt. entry > 150' above current alt. and pos. 
entered. 

When the [position] choice is [placebearingdistance] and the 
FMC determines that the associated [fixname] identifier has 
duplicates in the NDB, then the optional [latitudelongitude will 
be included in the downlink. 

12 

AT [position] REQUEST DESCENT TO 
[altitude] 

25 

E 

Selected when alt. entry > 150' below current alt. and pos. 
entered. 

When the [position] choice is [placebearingdistance] and the 
FMC determines that the associated [fixname] identifier has 
duplicates in the NDB, then the optional [latitudelongitude will 
be included in the downlink. 

H 

AT [time] REQUEST CLIMB TO [altitude] 

21 

E 

Selected when alt. entry > 150’ above current alt. and time 
entered. 


AT [time] REQUEST DESCENT TO [altitude] 

24 

E 

Selected when alt. entry > 150' below current alt. and time 
entered. 

mm 

(message not supported) 






Lateral Off-Set Requests 


I2H 

Additional Information 

im 

REQUEST OFFSET [direction] [distanceOffset] 

64 

E 

Selected when offset entered. 

16 

AT [position] REQUEST OFFSET [direction] 
[distanceOffset] 

65 

E 

Selected when offset and pos. entered. 

When the [position] choice is [placebearingdistance] and the 
FMC determines that the associated [fixname] identifier has 
duplicates in the NDB, then the optional [latitudelongitude will 
be included in the downlink. 

U 

AT [time] REQUEST OFFSET [direction] 
[distanceOffsetl 

66 

E 

Selected when offset and time entered. 



Speed Requests 



Additional Information 

18 

REQUEST [speed] 

106, 

111- 

114 

E 

Selected when speed entered. 

e m 

(message not supported) 

EDiHi 





Voice Contact Requests 



Additional Information J 


REQUEST VOICE CONTACT 




3M 

(message not supported) 
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Route Modification Requests 


1233 

Additional Information 

22 

REQUEST DIRECT TO [position] 

74 

E 

Selected when position entered. 

When the [position] choice is [placebearingdistance] and the 
FMC determines that the associated [fixname] identifier has 
duplicates in the NDB, then the optional [latitudelongitude will 
be included in the downlink. 

23 

REQUEST [procedureName] 

81 

P 

On ground, defaults to departure procedure selected on 
DEPARTURES page; in air, defaults to arrival or approach 
procedure selected on ARRIVALS pages. 

24 

REQUEST ROUTE CLEARANCE RTE[x] 
or 

REQUEST ROUTE CLEARANCE MODIFIED 
RTE[x] 

80 

■ 

Select RTE1 or RTE2. Provisional route will be sent if pending 
modification to selected route exists. 

Print to see full text of [routeclearance]. 


REQUEST CLEARANCE 




EEM 

(message not supported) 




■ 

REQUEST WEATHER DEVIATION UP TO 
[direction] [distanceOffset] 

82 

P, E 

Selected when offset entered and DUE TO WEATHER 
selected. 

HU 

REQUEST HEADING [degreesl 

94 

E 

Selected when heading entered. 

BH 

REQUEST GROUND TRACK [degrees] 

95 

E 

Selected when ground track entered. 
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Reports 


LEAVING [altitude] 


CLIMBING TO [altitude] 


DESCENDING TO [altitude] 


PASSING [position] 


PRESENT ALTITUDE [altitude] 


33 | PRESENT POSITION [position] 


PRESENT SPEED [speed] 


PRESENT HEADING [degrees] 


PRESENT GROUND TRACK [degrees] 


LEVEL [altitude] 


ASSIGNED ALTITUDE [altitude] 


ASSIGNED SPEED [speed] 


ASSIGNED ROUTE RTE[x] 


BACK ON ROUTE 


42 |NEXT WAYPOINT [position] 


NEXT WAYPOINT ETA [time] 


44 |ENSUING WAYPOINT [position] 


45 |REPORTED WAYPOINT [position] 


REPORTED WAYPOINT [time] 
1 


SQUAWKING [beaconCode] 





REACHING [altitude]_ 


REACHING BLOCK [altitude] TO [altitude] 


ASSIGNED BLOCK [altitude] TO [altitude] 


Additional Information 


[altitude] default based on uplink. 


[altitude] defaults to MCP alt.; transmitted with DL#s 32 and 48 
when MCP alt > 150 ft above baro-corrected altitude 


[altitude] defaults to MCP alt.; transmitted with DL#s 32 and 48 
when MCP alt > 150 ft below baro-corrected altitude 


[position] default based on uplink. 


[altitude] defaults to baro-corrected alt 


[position] defaults to Master FMC lat./lon. 

When the [position] choice is [placebearingdistance] and the 
FMC determines that the associated [fixname] identifier has 
duplicates in the NDB, then the optional [latitudelongitude will 
be included in the downlink. 


[speed] defaults to speed in Mach when above 29000; in CAS, 
otherwise. 


[degrees] defaults to Master FMC magnetic or true heading. 


[degrees] defaults to Master FMC magnetic or true ground 
track. 


[altitude] default based on uplink. 


[altitude] defaults to MCP alt. 


|[speed] defaults to speed in Mach when above 29000; in CAS, 
otherwise. 


[routeClearance] set to active route; RTE1 or RTE2 displayed 
Ion VERIFY REPORT page. 


[position] defaults to Master FMC active route active waypoint. 
When the [position] choice is [placebearingdistance] and the 
FMC determines that the associated [fixname] identifier has 
duplicates in the NDB, then the optional [latitudelongitude will 
be included in the downlink. 


[time] defaults to Master FMC active route active waypoint 
ETA. 


[position] defaults to Master FMC active route next waypoint. 
When the [position] choice is [placebearingdistance] and the 
FMC determines that the associated [fixname] identifier has 
duplicates in the NDB, then the optional [latitudelongitude will 
be included in the downlink. 


[position] defaults to Master FMC active route last waypoint. 
When the [position] choice is [placebearingdistance] and the 
FMC determines that the associated [fixname] identifier has 
duplicates in the NDB, then the optional [latitudelongitude will 
be included in the downlink. 


[time] defaults to Master FMC active route last waypoint ATA. 


Box prompts displayed. 


[positioncurrent] = Master FMC lat./lon. at time message 
created; [timeatpositioncurrent] = time at which message 
created; [altitude] = left ADC baro-corrected alt at time 
message is created; [fixnext] = Master FMC active route active 
waypoint; [timeetaatfixnext] = Master FMC active route active 
waypoint ETA; [fixnextplusone] = Master FMC active route next 
waypoint; [timeetadestination] = master FMC destination ETA; 
[temperature] = SAT in deg C; [winds] = Master FMC wind 
speed in English and direction; [speed] = Master FMC Mach 
target; [reportedwaypointposition] = Master FMC active route 
last waypoint, [reportedwaypointtime] = Master FMC active 
route last waypoint ATA; [reportedwaypointaltitude] = altitude at 
the last (sequenced) waypoint. 

When the [fixnext], [fixnextplusone], or 
[reportedwaypointposition] choice is [placebearingdistance] and 
the FMC determines that the associated [fixname] identifier has 
duplicates in the NDB, then the optional [latitudelongitude] will 
be included in the downlink. 

An abbreviated position report is transmitted with DL#56 (see 
table 4) 


(altitude] default based on uplink._ 


[altitudes] default based on uplink. 


Selection when xxxxx to xxxxx entered. 
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78 

AT [time] [distance] [toFrom] [position] 

181 

mm 

ATIS [atisCode] 

EEMI 

80 

DEVIATING [direction][distanceoffset] OF 

137, 


ROUTE 

140, 



142, 

s 


147 


[time] defaults to current time; [Distance] default based on 
Master FMC prediction; [toFrom] and [position] defaults based 
on uplink. 


Box prompt displayed. 


Defaults to offset displayed on active RTE page. Automatically 
transmitted with DL#'s 40, 42, 44, and 48 when offset active. 




Negotiation Requests 


WHEN CAN WE EXPECT [speed] 


(message not supported) 



Additional Information 


Selected when [speed] entered. 


WHEN CAN WE EXPECT BACK ON ROUTE 


52 WHEN CAN WE EXPECT LOWER ALTITUDE 9, 

10,15, 

16 


WHEN CAN WE EXPECT HIGHER ALTITUDE 7, 8,13, 

14 


WHEN CAN WE EXPECT CRUISE CLIMB TO 17,18 E 
[altitude] 



[Selected when altitude entered 



Emergency Messages 



Additional Information 


PAN PAN PAN 

N/A 

P 

Message is intended to be sent alone, not in combination with 
56-61. 


MAYDAY MAYDAY MAYDAY 




57 

[remainingFuel] OF FUEL REMAINING AND 
[remainingSouls] SOULS ON BOARD 

131 

■ 

Fuel defaults to minimum of Master FMC or totalizer values, in 
time remaining (hh+mm); box prompts for SOB. Can also send 
data in an Emergency Report. 

mm 

CANCEL EMERGENCY 

LW-1 



59 

DIVERTING TO [position] 
or 

DIVERTING TO [position] VIA ROUTE[x] 

N/A 


Position defaults to active destination; [routeClearance] set to 
active route if [position] in active or modified route. 

When the [position] choice is [placebearingdistance] and the 
FMC determines that the associated [fixname] identifier has 
duplicates in the NDB, then the optional [latitudelongitude will 
be included in the downlink. 


OFFSETTING [direction] [distanceOffset] 


E 

Selected when offset entered. 

61 

DESCENDING TO [altitude] 

N/A 

P 

[altitude] defaults to MCP altitude. - automatically selected 
when MCP alt >150 ft below current alt when MAYDAY 
selected. 



System Management Messages 



Additional Information 

62 

System Message (ERROR [errorlnformation]), 
no display on CDU 

mult 

N 

Message is automatically sent when uplink which cannot be 
decoded is received. This is a system message which is not 
dipslayed to the crew. 


System Message (NOT CURRENT DATA 
AUTHORITY), no display on CDU 

mult 

N 

Message is automatically sent when appropriate. This is a 
system message which is not displayed to the crew. 


System Message ([icaoUnitName]), no display 
on CDU 

163 

N 

Message is automatically sent when appropriate. This is a 
system message which is not displayed to the crew. 


System Message ([versionNumber]), no display 
on CDU 

163 

N 

Message is automatically sent when appropriate. This is a 
system message which is not dipslayed to the crew. 
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Additional Messages 


[ 2^21 

Additional Information 

■ 

DUE TO WEATHER 

mult 

p 

May be added to 'UNABLE' or 'NEGATIVE' response or an 
altitude or speed request. 


DUE TO AIRCRAFT PERFORMANCE 

mult 

p 

May be added to 'UNABLE' or 'NEGATIVE' response or an 
altitude, speed, or offset request. 


[freetext] 

mult 

E 

May be sent with reports, requests & 'UNABLE' or 'NEGATIVE' 
response or alone. 

67b 

WE CAN ACCEPT [altitude] AT [time] 

148 

■ 

[altitude] defaults based on uplink, [time] defaults to box 
prompts. 

FMC formats free text downlink since no message element 
defined. 

67c 

WE CAN ACCEPT [speed] AT [time] 

151 


[speed] defaults based on uplink, [time] defaults to box 
prompts. 

FMC formats free text downlink since no message element 
defined. 

67d 

WE CAN ACCEPT [direction][distanceoffset] AT 
[time] 

152 


[direction] and [distanceoffset] default based on uplink, [time] 
defaults to box prompts. 

FMC formats free text downlink since no message element 
defined. 


WE CANNOT ACCEPT [altitude] 

148 

P 

[altitude] defaults based on uplink. FMC formats free text 
downlink since no message element defined. 


WE CANNOT ACCEPT [speed] 

151 

P 

[speed] defaults based on uplink. FMC formats free text 
downlink since no message element defined. 


WE CANNOT ACCEPT 
[direction][distanceoffset] 

152 

P 

[direction] and [distanceoffset] default based on uplink. FMC 
formats free text downlink since no message element defined. 

67h 

WHEN CAN WE EXPECT CLIMB TO [altitude] 

13,14 

E 

[altitude] defaults to dash prompts. FMC formats free text 
downlink since no message element defined. Note that there 
will be no automatic correlation between this downlink and the 
corresponding uplink. 

67i 

WHEN CAN WE EXPECT DESCENT TO 
[altitude] 

15,16 

E 

[altitude] defaults to dash prompts. FMC formats free text 
downlink since no message element defined. . Note that there 
will be no automatic correlation between this downlink and the 
corresponding uplink. 

MM 

NOT CONSISTENT. RESEND 

0,5 

P 

May be added to UNABLE or NEGATIVE response 

Eaa 

UNLOADABLE CLEARANCE 

0,5 

P 

May be added to UNABLE or NEGATIVE response 

68 

[freetext] 

mult 

P 

May be sent with emergency report or alone for an emergency 
message. Ground should treat DL #68 with higher priority than 
DL #67. 

em 

MAINTAIN OWN SEPARATION AND VMC 


P 

May be added to an altitude request. 

tm 

AT PILOTS DISCRETION 


P 

May be added to an altitude request. 


Rev: B 


D926T0280 


100 






























































A.4 [ROUTECLEARANCE] VARIABLE ENCODING TABLE 

The constituent variables of the [routeclearance] variable are all optional. If the data associated with a particular variable do not exist in the 
selected route, then no data are encoded for that variable when an element containing the [routeclearance] variable is sent in a downlink. 
The "selected route" is as described in the DOWNLINK MESSAGE ELEMENTS table A.3 above, elements 24, 40, and 59. 

When encoding a [placebearingdistance] or [publishedidentifier] for which duplicates exist in the NDB for the associated [fixname], the 
optional [latitudelongitude] will be included with the [placebearingdistance] or [publishedidentifier] in the downlink. 

[routeclearance] VARIABLE ENCODING TABLE 


Variable Name 

Data Source 

[airportdeparture] 

Origin airport for the selected route. 

[airportdestination] 

Destination airport for the selected route. 

[runwaydeparture] 

Departure runway ([runwaydirection] and [runwayconfiguration]) for the selected route. 

[proceduredeparture] 

Departure procedure and departure transition for the selected route. 

[runwayarrival] 

Arrival runway ([runwaydirection] and [runwayconfiguration]) for the selected route. 

[procedureapproach] 

Approach procedure and approach transition for the selected route. 

Approach procedures with eight-character identifiers (e.g., ILS2 24L) are encoded as follows: 

The approach type and multiple approach character code (e.g., ILS2) are encoded as the [procedureapproach] 
variable. 

The runway number and direction (e.g., 24L) are encoded into the [runwayarrival] variable. 

Note that breaking the procedure identifier in this manner is necessary, as the DO-219 
[procedurename] variable has a maximum size of 6 characters. 

[procedurearrival] 

Arrival procedure and arrival transition for the selected route. 

[airwayintercept] 

NOT USED - FMC converts to publishedidentifier followed by an airway after entry/loading. 

[routeinformation] 

En route data for the selected route. All [routeinformation] variables are encoded in the order in which they occur 
in the selected route. 

The position of any intercept course from leg will be encoded in the routeinformation, inserted at the correct 
position within the selected route. (See also [interceptcoursefrom], below) 

[routeinformationadditional] 


[routeinformationadditional] 

[atwalongtrackwaypoint- 

sequence] 

NOT USED - ATWs (Along Track Waypoints) are stored in the FMC and sent in downlinks as 
[placebearingdistance]s. 
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Variable Name 

Data Source 

[routeinformationadditional] 

[reportingpoints] 

NOT USED - Reporting Points are stored in the FMC and sent in downlinks as [latitudelongitude]s. 

[routeinformationadditional] 

[interceptcoursefrom] 

Position and outbound course for each intercept course from leg in the route 

[routeinformationadditional] 

[interceptcoursefrom] 

[interceptcourse- 

fromselection] 

The position of the intercept course from leg will be encoded as a [publishedidentifier], 
[placebearingdistance], or [latitudelongitude]. 

[routeinformationadditional] 

[interceptcoursefrom] 

[degrees] 

Outbound course associated with a given intercept course from leg in the selected route. 

If the Outbound Course is in degrees magnetic, then [degrees] are encoded as choice value 0 
(degreesmagnetic). 

If the Outbound Course is in degrees true, then [degrees] are encoded as choice value 1 (degreestrue). 

[routeinformationadditional] 

[holdatwaypoint] 

Hold data and associated position for each holding pattern in the selected route. 

[routeinformationadditional] 

[holdatwaypoint] 

[position] 

Position for a given hold in the selected route. 

If the [position] variable does not match an identifier in the FMC's Navigation Database or is not a Place 
Bearing Distance, then the [position] is encoded as choice value 3 (latitudelongitude). 

Otherwise, the [position] is encoded as choice value 0 (fixname), 1 (navaid), 2 (airport), or 4 
(placebearingdistance), as appropriate. 

[routeinformationadditional] 

[holdatwaypoint] 

[holdatwaypointspeedlow] 

Speed constraint associated with a given hold in the selected route. 

The [speed] is encoded as choice value 0 (speedindicated). 

[routeinformationadditional] 

[holdatwaypoint] 

[atwaltitude] 

Altitude constraint associated with a given hold in the selected route. 

The [altitude] is encoded as choice value 0 (altitudeqnh) or as choice value 6 (altitudeflightlevel). 

If a window constraint exists on a hold, then the [atwaltitude] is treated as follows: 

If the flight phase is climb, the higher altitude (XXXB) is considered the [altitude] and the 
[atwaltitudetolerance] is encoded as choice value 2 (atorbelow); and 

If the flight phase is cruise or descent, the lower altitude (XXXA) is considered the [altitude] and the 
[altitudetolerance] is encoded as choice value 1 (atorabove). 
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Variable Name 

Data Source 

[routeinformationadditional] 

[holdatwaypoint] 

[holdatwaypointspeedhigh] 

NOT USED 

[routeinformationadditional] 

[holdatwaypoint] 

[direction] 

Turn direction (left or right) associated with a given hold in the selected route. 

[routeinformationadditional] 

[holdatwaypoint] 

[degrees] 

Inbound course associated with a given hold in the selected route. 

If the Inbound Course for the hold is in degrees magnetic, then [degrees] are encoded as choice value 0 
(degreesmagnetic). 

If the Inbound Course for the hold is in degrees true, then [degrees] are encoded as choice value 1 
(degreestrue). 

[routeinformationadditional] 

[holdatwaypoint] 

[EFCtime] 

Expect Further Clearance Time associated with a given hold in the selected route. 

[routeinformationadditional] 

[holdatwaypoint] 

[legtype] 

Leg Distance, if specified for a given hold in the selected route. 

Otherwise, Leg Time associated with a given hold in the selected route. 

If a Leg Distance is specified, then [legdistance] is encoded as choice value 0 (legdistanceenglish). 

[routeinformationadditional] 

[waypointspeedaltitude] 

Speed and altitude constraint and associated position for each waypoint speed and altitude constraint in 
the selected route. 

[routeinformationadditional] 

[waypointspeedaltitude] 

[position] 

Position of a waypoint which has a corresponding altitude or speed and altitude constraint. 

If the [position] variable does NOT match an identifier in the FMC's Navigation Database or is not a 

Place Bearing Distance, then the [position] is encoded as choice value 3 (latitudelongitude). 

Otherwise, the [position] is encoded as choice value 0 (fixname), 1 (navaid), 2 (airport), or 4 
(placebearingdistance), as appropriate. 

[routeinformationadditional] 

[waypointspeedaltitude] 

[speed] 

Speed portion of speed/altitude constraint for a waypoint in the selected route. 

The [speed] is encoded as choice value 0 (speedindicated). 
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Variable Name 

Data Source 

[routeinformationadditional] 

[waypointspeedaltitude] 

[ATWaltitudesequence] 

Altitude portion of an altitude or speed/altitude or window altitude constraint associated with a waypoint in 
the selected route. 

The [altitude] is encoded as choice value 0 (altitudeqnh) or as choice value 6 (altitudeflightlevel). 

If a window constraint exists for a given waypoint, then the [ATWaltitudetolerance] for the lower of the 
two altitudes is encoded as choice value 1 (at or above) and the [ATWaltitudetolerance] for the higher of 
the two altitudes is encoded as choice value 2 (at or below). 

[RTArequiredtimeofarrival] 

RTA data for a position in the selected route. FMC can only have one at a time. 

[RTArequiredtimeofarrival] 

[position] 

Position of a waypoint which has a defined RTA. 

If the [position] variable does NOT match an identifier in the FMC's Navigation Database or is not a 

Place Bearing Distance, then the [position] is encoded as choice value 3 (latitudelongitude). 

Otherwise, the [position] is encoded as choice value 0 (fixname), 1 (navaid), 2 (airport), or 4 
(placebearingdistance), as appropriate. 

[RTArequiredtimeofarrival] 

[RTAtime] 

RTA time and time tolerance for a position in the selected route. 

[RTArequiredtimeofarrival] 

[RTAtolerance] 

NOT USED 
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A.5 PERMITTED GROUPINGS OF DOWNLINK MESSAGE ELEMENTS 

Response Message Elements: 

All Models: 

Elements 0, 2, 3, and 4 cannot be combined with any other message element in a 
downlink message. 

Elements 1 and 5 can be combined with elements 65, 66, and 67 in a downlink message. 
Request Message Elements: 

Vertical, Lateral Off-Set, Speed, and Route Modification Requests can be combined in a 
downlink message with the following restrictions. These request elements can also be 
combined with elements 65, 66, 67, 74, and 75. 

• elements 6,7,8,9,10,11,12,13,14, and 69 (all of the altitude requests) are mutually 
exclusive. (A request downlink message may contain only one altitude request). 

• elements 15, 16, 17, and 27 (all lateral offset requests and the weather deviation via 
offset request) are mutually exclusive. (A request downlink message may contain 
only one lateral offset request). 

Elements 20 and 25 can be combined with element 67 in a downlink message, but cannot 
be combined with any other message elements. 

Report Message Elements: 

With the exception of element 48, the flight crew is unable to formulate a 
report/confirmation downlink unless that report has been requested from the controller by 
means of the corresponding uplink report request. (Reference table 4 in section 5.4). 

All report message elements except element 48 can be combined with message element 
67. All report message elements are mutually exclusive, with the following exceptions. 

• element 32 can be combined with message elements 29 or 30, as defined in 
Downlink Message Element Table. 

• elements 40, 42, and 44 can be combined with message 80 as defined in Downlink 
Message Element Table. 

• element 48 can be combined with message elements 29, 30, or 80 as defined in 
Downlink Message Element Table. 

Negotiation Request Message Elements: 

Negotiation Requests can be combined in a downlink message with the following 
restriction. These elements can also be combined with 67. 

• elements 52, 53, and 54 are mutually exclusive. 

Emergency Message Elements: 

Emergency message elements can be combined in a downlink message with the 
following restriction. These elements can also be combined with 68. 

• elements 55 and 56 are mutually exclusive. 

• Element 58 cannot be combined with any other emergency message element 
Additional Message Elements: 

Elements 65, 66, 68, 74, and 75 cannot be transmitted as standalone messages. These 
elements must be combined with another message element as described above. 

Element 67 can be transmitted as a standalone message. 
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A.6 LIMITATIONS ON DOWNLINK VARIABLE CHOICES AND RANGES 

The following table describes the limitations on the choices and Data Entry ranges for each listed 
downlinkable variable. If a particular variable is not included in the following list, its absence 
indicates that there are no choice or range limits. 


Downlink Variable 

Choice Limit 

Entry Range Limit 

[altitude] 

1. If the message element is 28, 37, 72, or 76, then there is no 
limitation on the [altitude] choice. 

2. If the [altitude] is contained in the [routeinformationadditional] 
portion of [routeclearance] message elements 24, 40, or 59, 
then the [altitude] choices are restricted to choices 0 
(altitudeqnh) or 6 (altitudeflightlevel) 

3. If the message element is any of elements 6-14, 29, 30, 32, 
38, 77, 54, or 61, then the [altitude] choices are restricted to 
choices 0 (altitudeqnh), 1 (altitudeqnhmeters), or 6 
(altitudeflightlevel) 

[altitudeqnh] - per DO-219 

[altitudeqnhmeters] - per DO-219 

[altitudeflightlevel] - (FL030..FL431) 
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Downlink Variable 
[degrees] 


[distance] 


[distanceoffset] 


Choice Limit _ 

1. the [degrees] choice is limited to [degreesmagnetic] when the 
aircraft's heading is referenced to magnetic north and to 
[degreestrue] when the aircraft's heading is referenced to true 
north for the following message elements and variables. 

(Note that the aircraft's heading is referenced to true north 
only in the polar regions). 

a) If the message element is 35, 36, 70, 71 

b) If the [degrees] is contained in a [placebearingdistance] 
which is the [position] portion of message elements 11, 12, 

16, 22, 33, 42, 44, 45, or 59 

c) If the [degrees] is contained in a [placebearingdistance] 
which is the [fixnext], [fixnextplusone], or 
[reportedwaypointposition] of element 48 

2. the [degrees] choice is limited to [degreestrue] for the 
following message elements and variables: 

a) If the [degrees] is contained in a [placebearingdistance] 
which is defined as a [routeinformation] [publishedidentifier] in 
elements 24, 40, or 59 

b) If the [degrees] is contained in a [placebearingdistance] ] 
which is the [position] portion of any 
[routeinformationadditional] variable of elements 24, 40, or 59 

3. If the [degrees] is contained in a [placebearingdistance] which 

is the [position] portion of message elements 31 or 78, then 
there is no limitation on the [degrees] choice _ 

1. the [distance] choice is limited to [distancenm] for the 
following message elements and variables: 

a) If the [distance] is contained in a [placebearingdistance] 
which is the [position] portion of message elements 11, 12, 

16, 22, 33, 42, 44, 45, or 59 

b) If the [distance] is contained in a [placebearingdistance] ] 
which is the [position] portion of any 
[routeinformationadditional] variable of elements 24, 40, or 59 

c) If the [distance] is contained in a [placebearingdistance] 
which is the [fixnext], [fixnextplusone], or 
[reportedwaypointposition] of element 48 

d) If the [distance] is contained in a [placebearingdistance] 
which is defined as a [routeinformation] [publishedidentifier] in 
elements 24, 40, or 59 

2. If the [distance] is contained in a [placebearingdistance] 

which is the [position] portion of message elements 31 or 78, 
then there is no limitation on the [distance] choice _ 

The [distanceoffset] choice is limited to [distanceoffsetnm] for 
all downlink message elements containing the 
[distanceoffset] variable._ 


Entry Range Limit 


[distancenm] - (0..700) 


[distanceoffsetnm] - (0..99) 
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Downlink Variable 

Choice Limit 

Entry Range Limit 

[direction] 

The [direction] choice is limited to [left] or [right] for all 
downlink message elements containing the [direction] 
variable. 


[legdistance] 

The [legdistance] choice is limited to [legdistanceenglish] for 
all downlink message elements containing the 
[routeclearance] [routeinformationadditional] [holdatwaypoint] 
variable. 


[remainingsoulsl 


[remainingsoulsl - (1..999) 

[speed] 

1. If the message element is 18, 34, 39, or 49, then the [speed] 
choice is limited to [speedindicated] or [speedmach] 

2. If the message element is 48, then the [speed] choice is 
limited to [speedmach] 

3 If the [speed] is contained in the [ATWalongtrackwaypoint], 
[waypointspeedaltitude], or [holdatwaypoint] 
[holdatwaypointspeedlow] portion of the 
[routeinformationadditional] variable of elements 24, 40, or 

59, then the [speed] choice is limited to [speedindicated]. 

[speedindicated] - (100..380) 

[speedmach] - (.61 ...91) 

[windspeed] 

The [windspeed] choice is limited to [windspeedenglish] for 
downlink message element 48. (Element 48 is the only 
downlink element which contains this variable). 
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APPENDIX B - ADS REPORT DATA 

Information contained in ADS reports have been categorized into groups. The information groups 
and the individual pieces of data which make up the group shall be as described in the table 
below. 


ADS Data 

Data Source 

Basic ADS Group 


latitude 

flight management function calculated latitude 

longitude 

flight managment function calculated longitude 

altitude 

uncorrected altitude (referenced to standard day 
pressure of 29.92 in. of Hg) 

time 

GPS UTC time, if available, or flight deck clock time 
when GPS unavailable. 

figure-of-merit 


navigation redundancy discrete 

If GPS is installed: 1, if there are two flight 
management functions and two GNSSUs providing 
valid input to the flight management functions; 0, 
otherwise 

If GPS is not installed: 1, if there are two or more 
inertial reference units providing valid position data to 
the flight management function; 0, otherwise 

position determination accuracy 

Level 0-7, which reflects the accuracy of the FMC 
position and time being reported. 

TCAS state discrete 

1, if TCAS is providing valid data to the ADS 
application; 0, otherwise 

Flight Identification Group 


flight ID 

flight ID flight-crew entered 

Earth Reference Group 


true track 

flight management function calculated true track 

ground speed 

flight management function calculated ground speed 

vertical rate 

inertial vertical rate 

Air Reference Group 


true heading 

inertial true heading 

mach speed 

air data mach 

vertical rate 

inertial vertical rate 

Airframe Identification Group 


24-bit ICAO Identifier 

not provided 
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ADS Data 

Data Source 

Meteorological Group 


wind speed 

flight management function calculated wind speed 

true wind direction 

flight management function calculated true wind 
direction 

temperature 

air data static air temperature 

Predicted Route Group 


latitude at next waypoint 

flight management function active waypoint latitude 

longitude at next waypoint 

flight management function active waypoint longitude 

altitude at next waypoint 

flight management function predicted active waypoint 
altitude 

estimated time at next waypoint 

flight management function predicted active waypoint 
ETA 

latitude at next+1 waypoint 

flight management function next waypoint latitude 

longitude at next+1 waypoint 

flight management function next waypoint longitude 

altitude at next+1 waypoint 

flight management function predicted next waypoint 
altitude 
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Aircraft Intent Groups 


Intermediate Projected Intent Group 

The flight management function locates up to 10 
points in the active flight plan, between the current 
position and the requested time, where a change to 
the flight management function target altitude, target 
speed or course is predicted. For each of these 
points, an Intermediate Projected Intent Group is 
formed. 

distance 

flight management function calculated distance from 
current position for the first point; flight management 
function calculated distance from the previous point 
for the remaining points. 

true track 

flight management function calculated track from 
current position for the first point, FMC track from the 
previous point for the remaining points. 

altitude 

flight management function calculated projected 
altitude at the point 

projected time 

flight management function calculated projected travel 
time to the point 

Fixed Intent Group 

The flight management function locates the point at 
which the aircraft is projected to be along the active 
flight plan at the requested time. If the requested time 
falls past the end of the route, the last waypoint will be 
reported. 

latitude 

flight management function projected latitude at the 
point 

longitude 

flight management function projected longitude at the 
point 

altitude 

flight management function projected altitude at the 
point 

projected timet 39 ! 

Travel time or flight management function projected 
travel time for the last waypoint along the active route 


This refers to a period of time (e.g. 2 hours) rather than a distinct time (e.g. 2:00pm). 
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APPENDIX C - TRACEABILITY OF SAFETY ASSUMPTIONS TO SR&O REQUIREMENTS 

The following table lists the safety requirements on systems and procedures which were 

considered as assumptions in developing the FHA. The reference section numbers in brackets 

provide traceability to the assumptions in the ATS SR&O where applicable. 

1. All voice communication capability will be retained (HF, VHF, SATCOM) and would be 
considered as a backup to the data link functionality. There will be no proposed change to 
the Master Minimum Equipment List (MMEL) for HF or VHF communication equipment based 
on the initial FANS 1 certification. [6.10] 

2. There will be established procedures for each communication failure condition. The 
procedures must account for possible loss of messages and indicate how long a pilot or 
controller should wait before deciding a message has been lost. The time-out value must be 
small enough to assure adequate reaction time based on the separation minima. [6.10] 

3. The AFN, ATC DL, and ADS FANS 1 software will be developed per level C of DO-178B or 
per an equivalent or agreed to certification level. [8.1.1, 8.3.1, 8.4.1] 

4. ATC Workstations will be developed and modified to equivalent guidelines of DO-178B Level 
C. [8.1.3.2, 8.3.3, 8.4.3] 

5. All LRUs that supply data to the AFN, ATC DL, and ADS applications for logon information 
and reports will be developed per level C of DO-178B or per an equivalent or agreed to 
certification level. [8.1.1,8.3.1, 8.4.1] 

6. Air Traffic Control procedures will use ADS periodic reporting or manual ATC DL position 
reports in addition to ARMed reports (if such functionality is provided on a particular airplane 
model) and/or ADS Event reports. [6.10] 

7. Include the tail number of the airplane in each message encapsulated by the CRC. [8.2.1.1] 

8. Generate and validate a 16 bit or better CRC for the tail number and data of each ATC DL, 
ADS, and AFN message. [8.2.1.1] 

9. ATC procedures will be established which will not allow the controller to issue clearances to 
an airplane which is not in his area of control. [6.10] 

10. ATC procedures, systems and personnel will not use AOC DL. [6.10] 

11. If the printer is certified to level D of DO-178B or is non-essential, confirm print-only data 
using some other means, or do not use print-only data for those data which could contribute 
to a MAJOR failure effect. [6.10] 

12. If the printer is certified to level D of DO-178B or is non-essential, ATC clearance data 
received through the ATC DL Application which can only be viewed on the cockpit printer 
must be independently verified per approved operational procedures. [6.10] 

13. All ATC DL data which could contribute to a major failure effect must be displayable on a flight 
deck Display Unit. [8.4.1] 

14. The crew shall reject clearances that they cannot comply with and current air traffic 
procedures will be used to resolve any resultant conflicts. [6.10] 

15. The ATC Facility shall have the means to detect an erroneous flight identifier or tail number 
(aircraft registration) received in the end system (CRC'd) portion of the AFN logon message. 
[ 6 . 10 ] 
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APPENDIX D - VALIDATION REQUIREMENTS FOR ASSURANCE OF CONTINUED INTEROPERABILITY 

The following table details the traceability between the requirements in this document, which test step validates that requirement, and which 
equipment modification would force rerun of the test. 


8.1 

ATS Facilities Notification Function (AFN) 

TEST 

DRIVER 

Test Step 

8.1.1 

Allocation to Airplane Environment 




paragraphs a & b 

AFN 

APPLICATIO 

N SYSTEM 

Cert 


paragraph c 

Procedure 



paragraphs d through i 

AFN 

APPLICATIO 

N SYSTEM 

Cert 

8.1.2 

Allocation to Satellite Environment 




all paragraphs 

Never 

Not Req. 

8.1.3 

Allocation to Ground Environment 



8.1.3.1 

Allocation to Service Provider Component 




all paragraphs 

DSP 


8.1.3.2 

Allocation to ATC Facility Component 




all paragraphs 

ATC 


8.2 

Datalink 



8.2.1 

Allocation to Airplane Environment 



8.2.1.1 

ATS application system 
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all paragraphs 

ATS 

Application 

System 

Cert 

8.2.1.2 

ACARS function 



8.2.1.2.1 

ACARS Requirements 




all paragraphs 

ACARS 

AEIT or Cert 

8.2.1.3 

SATCOM 




all paragraphs 

SATCOM 

AEIT 

8.2.1.4 

VHF Radio 




all paragraphs 

VHF 


8.2.2 

Satellite Environment 




all paragraphs 

Satellite 



8.2.3 

Ground Environment 

TEST 

DRIVER 

Test Step 

8.2.3.1 

VHF Sub-Network Component 




all paragraphs 

DSP 


8.2.3.2 

Service Provider Component 




all paragraphs 

DSP 


8.2.3.2.1 

Internetworking 




all paragraphs 

DSP 


8.2.3.2.2 

Recording of ATS Messages 




all paragraphs 

DSP 


8.2.3.3 

Allocation to ATC Facility Component 
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paragraph a 

Airline 



paragraphs b through i 

ATC 


8.2.4 

Datalink Performance 




all paragraphs 

Any 


8.2.5 

Datalink Operational Requirements 




all paragraphs 

Never 

Not Req. 

8.3 

Automatic Dependent Surveillance (ADS) 



8.3.1 

Allocation to Airplane Environment 




all paragraphs 

ADS 

APPLICATIO 

N 

Cert 

8.3.2 

Allocation to Satellite Environment 




all paragraphs 

Never 

Not Req. 

8.3.3 

Allocation to Ground Environment 




paragraph a 

Airline 



paragraphs b through j 

ATC 


8.4 

ATC Datalink (ATC DL) 



8.4.1 

Allocation to Airplane Environment 




all paragraphs 

ATC DL 
APPLICATIO 

N 

Cert 

8.4.2 

Allocation to Satellite Environment 




all paragraphs 

Never 

Not Req. 

8.4.3 

Allocation to Ground Environment 




all paragraphs 

ATC 
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APPENDIX E - DIFFERENCES BETWEEN ARINC 745-2, RTCA DO-212 AND ADSP ATC/ADS 
GUIDELINES 


ADS Requirement 

ARINC 745-2 
(section) 

RTCA DO- 
212 

(section) 

ICAO ADSP Guidelines 
as of 11-94 

Periodic Report Rate 
Upon Emergency 
Mode Termination 
(per connection) 

No effect (3.2.5) 

Same as 
ARINC 745- 
2 

(2.2.1.3.1.2) 

Rate that existed before 
emergency was initiated is 
reinstated upon cancellation of 
emergency mode by either pilot or 
ATC 

Airborne End 

System Priority of 

ADS Messages 

Emergency reports 
replace other periodic 
reports. Event 

Reports continue. 

Same as 
ARINC 745- 
2 

(2.2.1.3.1.1) 

1. Emergency reports 

2. Reports containing 

Projected Profile Group 

3. Remaining reports 

Event Report 

Triggers 

Event report triggers, 
except for waypoint 
events, remain armed 
only until the event 
occurs or the contract 
is canceled. (3.2.2.2) 

Same as 
ARINC 745- 
2 (2.2.1.2.2) 

Event report triggers remained 
armed (and trigger once per 
minute) until the event contract is 
canceled. (Note: This only works 
for the newly defined events.) 

Extended Projected 
Profile Block On- 
Request Group 

Not defined 

Not defined 

Defined as tag 25 and can 
containuses repetitive next 
waypoint groups for 1 -12820 
waypoints or next 15-96 minutes.. 
(Note: The definition is 
inconsistent as to whether or not 
an uplink modulus is defined for 
this on-request group.) 

Weather On- 
Request Group 

Not defined, although 
Air Reference Group 
uses the same tag 
(16) and contains 
same data except for 
Turbulence. (3.2.2.1 
and 3.2.3) 

Same as 
ARINC 745- 
2 (2.2.1.2.1 
and 2.2.1.4) 

Replaces Air Reference Group. 
Contains same data, plus 

Turbulence 

Periodic Report Rate 
upon Emergency 

Mode Initiation (per 
connection). 

64 second period or 
the existing rate, 
whichever is less 

Same as 
ARINC 745- 
2 

(2.2.1.3.1.1) 

60 second period or 1/2 of existing 
rate, whichever is less 

Periodic Contract 

Request 

Acknowledgement 

Always sent with first 
periodic report 

Same as 
ARINC 745- 
2 (2.2.1.4) 

Sent alone if report cannot be sent 
within 5 seconds. Otherwise, sent 
with first periodic report. 
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ADS Requirement 

ARINC 745-2 
(section) 

RTCA DO- 
212 

(section) 

ICAO ADSP Guidelines 
as of 11-94 

Event Contract 
Requests 

1. Waypoint Change 
(20) 

2. Lateral Deviation 
Change (10) 

3. Altitude Range 
(Ceiling/Floor - 19) 

4. Vertical Rate 
Change (18) 

(3.2.2.2) 

Same as 
ARINC 745- 
2 (2.2.1.2.2) 

Same as ARINC 745-2, plus: 

1. Air Speed Change (22) 

2. Ground Speed Change (23) 

3. Heading Change (24) 

4. Extended Projected Profile 
Change (25) 

5. FOM Change (26) 

6. Track Angle Change (27) 

7. Altitude Change (28) 

Time Stamp 

Accuracy 

Not specified 


Within + 1 sec of UTC 

Response Time 

ADS response 
received within 2 
seconds of receiving 
request from 

Transport Layer; 

Within 1 second of 
period expiration or 
event trigger (3.2.3) 

Within 5 
seconds of 
receiving 
request from 
Transport 
Layer; 

Within 2.5 
seconds of 
period 

expiration or 
event trigger 
(2.2.1.4) 

Within 5 seconds of receiving 
request from Transport Layer; 

Within .5 seconds of period 
expiration or event trigger.Not 
specified 

Emergency Contract 
Report Modification 

Can be modified just 
like normal mode 
contract 

Same as 
ARINC 745- 
2 (2.2.1.2.2) 

Only report rate (not report 
content) can be modified. 


This is an assumption, not a requirement. 
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APPENDIX FI - DIFFERENCES BETWEEN THE DESIRED FANS 1 REQUIREMENTS AND 
THE ACTUAL IMPLEMENTATION 

The following are differences between the desired FANS 1 requirements and the actual 
implementation. It should be assumed that each of these items will be considered for change, if 
and when, the FANS 1 software is upgraded. For some items there is a requirement placed on 
another system to work around the problem; the remaining items are for information only. 

I. AUTOMATIC DEPENDENT SURVEILLANCE (ADS) 

CHARACTERISTICS OF FMC-GENERATED DOWNLINKS 

1_._ Correlation of ADS Intent Data with timestamp in the Basic Report 

The FMC computes ADS Intent data on a periodic basis so that intent data will always be 
available when required for an ADS report. As such, the intent data may be “stale” with 
respect to the timestamp contained within the Basic group with which the intent data are 
transmitted. Lab analysis indicates the difference between the time the intent data are 
computed and the timestamp in the Basic group may be as long as 30 seconds. 

REQUIREMENT ON ATC FACILITY: If ADS intent data are used for conflict probe or 
conformance monitoring, then the ground automation shall account for the position 
uncertainty introduced by the time difference described above. 


II. ATC DATA LINK (ATC DL) 

A. CHARACTERISTICS OF UPLINK ELEMENT ENCODING 

1. Restriction on the use of runway waypoints in the [position] and [publishedidentifier] 
variables when using uplink elements 73, 74, 77, 79, 80 and 83. 

The FMC does not currently search its NDB runway file for a match to an uplink 
[position] or [publishedidentifier] variable. The FMC is supposed to allow the 
uplink of an arrival runway as a [position] or [publishedidentifier]. The 
[runwayarrival] variable in message elements 73 and 80 can be used. 

REQUIREMENT ON THE ATC FACILITY: To ensure the loadability of elements 
73, 74, 77, 79, 80, and 83, a runway waypoint shall not be encoded as a [position] 
or [publishedidentifier] variable when any of these elements is included in an 
uplink. 

2. Restriction on the number of [routeclearance] [routeinformation] variables 

The FMC is unable to load a [routeclearance] which contains 120 
latitudelongitude’ [routeinformation] items. Attempting to load such a route 
clearance causes the FMC to reset, resulting in a loss of all existing flight plan 
data. The FMC is able to load a [routeclearance] which contains 80 
‘latitudelongitude’ [routeinformation] items. 

REQUIREMENT ON THE ATC FACILITY: ATC shall not transmit a 
[routeclearance] containing more than 80 items in the [routeinformation] variable. 

2. Second of two airways will not load if the airways do not intersect at a named fix 

When two airways intersect but not at a named fix, the FMC is able to Load the 

first airway but cannot load the second. 

REQUIREMENT ON ATC FACILITY: Do not uplink a [routeclearance] message 

which includes consecutive airways that do not intersect at a named fix. 
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B. CHARACTERISTICS OF FMC-GENERATED DOWNLINKS 

1. Departure transition not included in downlink elements 24 or 40 

When the FMC transmits a [routeclearance] variable as part of downlink elements 
24 or 40, and the airplane is still in a departure transition (has sequenced all the 
departure procedure waypoints, and has not sequenced all the departure 
transition waypoints), then the FMC may omit the departure transition and 
departure procedure from the encoded [routeclearance]. 

REQUIREMENTS ON THE ATC FACILITY: None 

2. Sequenced departure procedure included in downlink element 24 

When the FMC transmits a [routeclearance] variable as part of downlink element 
24, and the airplane has not already sequenced the second en-route waypoint at 
the time the route is constructed for downlink, a sequenced departure procedure 
may be included in the downlinked [routeclearance]. 

REQUIREMENTS ON THE ATC FACILITY: None 

3. Place-bearing-distances in Position Reports may be encoded incorrectly 

When a Place-bearing-distance (PBD) is encoded as the [fixnext] or 
[fixnextplusone] and the PBD “parent” fix is a navaid or an airport, the PBD is 
incorrectly encoded as either a navaid or an airport. For example the PBD 
ABC120/10 would be encoded as ‘navaid’ ABCO. 

REQUIREMENT ON THE ATC FACILITY: None 
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APPENDIX F2 - PEGASUS ‘98 SOFTWARE CHANGES 

The following 757/767 FMC ATS function characteristics have been corrected in the Pegasus ‘98 
software version. 

I. AUTOMATIC DEPENDENT SURVEILLANCE (ADS) 

CHARACTERISTICS OF FMC-GENERATED DOWNLINKS 

1. Invalid altitude and ETA in waypoint change event report 

When the FMC’s active or next waypoint was changed by means of a flight plan 
modification, the FMC was unable to compute the predicted altitude and ETA 
before transmission of the resulting Waypoint Change Event report. The default 
altitude and time to go values were reported, as specified in ARINC 745-2. 

The FMC software has been changed such that the Waypoint Change Event report is 
delayed up to 5 seconds following a change to the active or next waypoint to allow 
the FMC to complete computation of the altitude and ETA predictions. 

2. Altitude in Basic Group vs. Predicted Altitudes 

The altitude in the Basic Group is an uncorrected standard altitude, while the 
altitude in the Predicted Route Group was a baro-corrected altitude. The desired 
implementation is that all altitudes be uncorrected standard altitudes. 

The FMC software has been changed such that all altitudes are reported as 
uncorrected standard altitudes. 

3. Waypoint Change Event Reports and Holding Fixes 

Insertion of a holding pattern as the active flight plan fix did not trigger a Waypoint 
Change event report. 

The ETA included in a Waypoint Change event report when the aircraft entered a 
holding pattern was always reported as zero. 

The FMC software has been changed as follows: 

• Insertion of a holding pattern as the active flight plan fix triggers a Waypoint 
Change event report. 

• The ETA included in a Waypoint Change event report when the aircraft 
enters a holding pattern is now reported as the correct value. 

II. ATC DATA LINK (ATC DL) 

A. CHARACTERISTICS OF UPLINK ELEMENT ENCODING 

Restriction on the use of the [proceduredeparture] variable 

If a SID and a runway-SID transition at a given airport had the same identifier, 
then when the FMC loaded a [routeclearance] variable containing a 
[proceduredeparture] with such a duplicate identifier, the runway-SID transition 
was loaded instead of the SID. 

The FMC software has been changed such thatif a SID and a runway-SID 
transition at a given airport have the same identifier, the FMC will load the full 
SID. 
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B. CHARACTERISTICS OF FMC-GENERATED DOWNLINKS 

1. Airway intersection point for consecutive airways not included in route clearance 
downlink 

When the FMC’s flight plan included consecutive airways and the airways crossed at 
a named waypoint, the airway intersection point was not included in a 
[routeclearance] downlink. The route data were encoded into the 
[routeinformation] as follows: the point at which the aircraft was to join the first 
airway was encoded as a [publishedidentifier], the first airway was encoded as an 
[airwayidentifier], the second airway was encoded as an [airwayidentifier], and the 
point at which the aircraft was to depart the second airway was encoded as a 
[publishedidentifier]. 

The FMC software has been changed such that the airway intersection point is 
included in a [routeclearance] downlink. 

2. FMC sends blank [icaofacilitydesignation] in response to unexpected connect request 

When the FMC received a connect request from a source other than the Current 
Data Authority or the specified Next Data Authority (if one existed), the FMC 
responded with a Disconnect Request and element 64 ([icaofacilitydesignation]). 
The [icaofacilitydesignation] was encoded as four space characters. The 
[icaofacilitydesignation] variable should have been encoded as the identifier for 
the Current Data Authority. 

The FMC software has been changed such that the [icaofacilitydesignation] of the 
Current Data Authority is correctly encoded into element 64 under the described 
condition. 

3. FMC does not include the optional [latitudelongitude] with [placebearingdistance] or 
[publishedidentifier] 

Table 4 in Section 5.4, Appendix 3, and Appendix A.4 state the following: 

“When encoding a [placebearingdistance] or [publishedidentifier] for 
which duplicates exist in the NDB for the associated [fixname], the 
optional [latitudelongitude] will be included with the [placebearingdistance] 
or [publishedidentifier] in the downlink”. 

The FMC did not include the optional [latitudelongitude] in the downlink. 

The FMC software has been changed such that the optional [latitudelongitude] is 
included with the [placebearingdistance] or [publishedidentifier] when the 
associated [fixname] is a duplicate. 

4. FMC encodes invalid characters in free text response to UL# 148 (WHEN CAN YOU 
ACCEPT [altitude]) 

When the FMC receives UL# 148 (WHEN CAN YOU ACCEPT [altitude]), it 
automatically formats a free text response for the flight crew to transmit. If the 
[altitude] variable in the uplink is specified in terms of ‘qnhmeters’ then the FMC 
displays the altitude to the flight crew with the feet equivalent in parentheses next 
to the meters value. When the FMC encoded the free text report, the feet 
equivalent and parentheses were included in the downlink (e.g., 
WE<sp>CAN<sp>ACCEPT<sp>5000M<sp>(16404FT)<sp>AT<sp>1255). 

The FMC software has been changed such that parentheses and feet equivalent 
of the metric altitude are not included in the downlink message. 

5. FMC may reject uplinked response to downlink which requires a response 
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When the FMC transmits a downlink message to the ACARS MU, the FMC holds 
that message in its downlink queue until it receives a network acknowledgment 
message back from the MU. If the FMC has not received the network 
acknowledgment after 5 minutes, then it automatically attempts to resend the 
message to the ACARS MU. An anomaly existed in the FMC which caused the 
FMC to reject an uplinked response to such a re-transmitted downlink. 
Specifically, it did not recognize the MRN in the uplink message as corresponding 
to an open downlink message. 

The FMC software has been changed such that the FMC will recognize an 
uplinked response to a re-transmitted downlink. 
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APPENDIX F3 - PEGASUS 00 SOFTWARE CHANGES 

The following 757/767 FMC ATS function characteristics have been corrected in the Pegasus ‘00 
software version. 

AUTOMATIC DEPENDENT SURVEILLANCE (ADS) 

CHARACTERISTICS OF FMC-GENERATED DOWNLINKS 

Intermediate Intent point with EFC time in hold 

An anomaly existed such that when the flight plan contained a holding pattern 
with an EFC time in the climb flight phase, the Aircraft Intend Group contained an 
Intermediate Intent point with an erroneous distance. 

The FMC software has been changed to correct this anomaly. 
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APPENDIX G - ATC DL ERROR PROCESSING 

The following lists the conditions under which the FMC will transmit an error message. These 
conditions are listed by the error code that will be transmitted in the downlink message. 

0) applicationError 

The FMC receives an uplink message (IMI=AT1) containing an invalid IA5String (e.g. 
element 169 [freetext]). (Downlink IMI=AT1). 

1) duplicateMsgldentificationNumber 

The FMC receives an uplink message (IMI=AT1) with an MIN equal the MIN of a previous 
uplink which is still OPEN. 

2) unrecognizedMsgReferenceNumber 

The FMC receives an uplink message (IMI=AT1) with an MRN and there is no OPEN 
downlink message in the FMC log with a matching MIN. (Downlink IMI=AT1). 

The FMC receives an uplink with IMI=CR1 and the uplink includes an MRN. (Downlink 
IMI=DR1). 

3) endServiceWithPendingMsgs 

The FMC receives an uplink message (IMI=AT1) containing element 161 and no other 
element and there are OPEN downlink messages, (downlink IMI=DR1), or 

The FMC receives an uplink message (IMI=AT1) containing element 161 plus another 
element requiring WILCO/UNABLE response and there are OPEN downlink messages 
and the pilot sends WILCO. (Downlink IMI=DR1). 

4) endServiceWithNoValidResponse 

The FMC receives an uplink message (IMI=AT1) containing element 161 and another 
element requiring no response or a response other than WILCO/UNABLE. (Downlink 
IMI=DR1). 

5) insufficientMsgStorageCapacity 

The FMC receives an uplink message (IMI=AT1) when the FMC log is full (see section 
5.4 for the capacity of the FMC log). (Downlink IMI=AT 1). 

The FMC receives an uplink message (IMI=AT1) containing a [routeclearance] variable 
larger than 918 bytes. (Downlink IMI=AT 1). 


6) noAvailableMsgldentificationNumber 

The FMC has only one MIN available that is not being used for a pending downlink 
message. (Downlink IMI=DR1). 

7) commandedTermination 

The pilot turns ATC DL OFF, changes the entered flight number, or changes the entered 
aircraft registration (tail number) or the FMC goes through "flight completion". (Downlink 
IMI=DR1). 
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8) insufficientData 

The FMC receives an uplink message (IMI=CR1 or ATI) without enough bits to define the 
header and one valid element, (If the uplink IMI=CR1, the downlink IMI=DR1. If the uplink 
IMI=AT1, the downlink IMI=AT1). or 

The FMC receives an uplink message (IMI=AT1) without enough bits to define all 
variables required for each element, (downlink IMI=AT1), or 

The FMC receives an uplink message (IMI=AT1) containing an IA5String and the string 
contains fewer characters than specified, (downlink IMI=AT1), or 

The FMC receives an uplink message (IMI=AT1) containing a [routeclearance] variable 
and a [waypointspeedaltitude] variable without a [speed] variable and without an 
[aTWaltitudej variable. (Downlink IMI=AT1). 

9) unexpected Data 

The FMC receives an uplink (IMI=AT1) with more than 5 message elements. (Downlink 
IMI=AT1). 

The FMC receives an uplink message (IMI=AT1) with more pad bits than required to 
make a full octet, (downlink IMI=AT1), or 

The FMC receives an uplink message (IMI=AT1) containing an IA5String and the string 
contains more characters than specified, (downlink IMI=AT1), or 

The FMC receives an uplink message with IMI=CR1 and an element other than 163, 
(downlink IMI=DR1), or 

The FMC receives an uplink message with IMI=CR1 and element 163 plus any other 
element. (Downlink IMI=DR1). 

10) invalidData 

The FMC receives an uplink with IMI=CR1 and either datum in element 163 is invalid. 
(Downlink IMI=DR1). 

The FMC receives an uplink message (IMI=AT1) with element 178 or 183-255, (downlink 
IMI=AT1), or 

The FMC receives an uplink message (IMI=AT1) with a variable outside its valid range. 
(Downlink IMI=AT1). 

16) reservedErrorMsg 

Not Used 
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